Author Topic: [Ndless] Help with bottleneck on color calcs only (Read 17487 times)

Matrefeytontias · « **on:** June 26, 2014, 06:25:50 am »

Hi guys,

I've been working on nKaruga since quite some time now, and although it's reasonably fast on monochrome TI-Nspires, it's accurately twice as slow on color calcs, although it's the same code running and that the monochrome screen is being configured in 16-bits mode by the game.

I have no idea why it's like this, I keep trying things and nothing changes. I even removed every drawing command except the screen update and the ship, and the speed stays the same. Since I'm really, really stuck, I thought of asking you guys.

The full source is here : https://github.com/matrefeytontias/nKaruga

It's also possible that it's n2DLib's fault, since it's used to interact with the screen : https://github.com/n2DLib/n2DLib

Feel free to fork it and submit PR, I'll be very happy to see things fixed because I don't know what to do.

Also, I have no color calc to test, only monochrome. Several people made tests for me.

Vogtinator · « **Reply #1 on:** June 26, 2014, 10:31:23 am »

Does nspire_emu show the same symptoms?

Matrefeytontias · « **Reply #2 on:** June 26, 2014, 10:40:46 am »

Nope, nspire_emu tells me the game is equally fast on both screen types.

Vogtinator · « **Reply #3 on:** June 27, 2014, 08:09:52 am »

Quote

I've been working on nKaruga since quite some time now, and although it's reasonably fast on monochrome TI-Nspires, it's accurately twice as slow on color calcs, although it's the same code running and that the monochrome screen is being configured in 16-bits mode by the game.

So you don't handle those different LCDs differently? Using the monochrome LCD in 16bpp mode like a color one looks awful.

aeTIos · « **Reply #4 on:** June 27, 2014, 08:40:34 am »

I've run a few tests and I'm fairly sure it's n2DLibs sprite drawing function. I already did test IkarugaX for you, and the time-to-scroll-sprite-over-screen time is almost the same, namely 06:55 seconds. When I take away the fullscreen pic on the background, it's suddenly three times as fast: 01:91 seconds. It was mentioned on IRC that the first versions of n2DLib (nFastGraphX) supposedly were faster (jetpack impossible 2). This has been proven wrong by porting the source to the newest version of n2DLib, see attached files. Hayleia told me that pictures are drawn to screen by copying them pixel-by-pixel to the screen. I don't know exactly what the nspire can do and what not, but I think you'll have to thoroughly re-think the way you are drawing sprites.
I really hope you can fix the lib though, I love how easy to use it is.

EDIT: Of course, this does not explain why it is almost twice as fast on the b/w series nspire, but because both methods for drawing (both with and without buffer) are about the same speed (should I say slow? that'd be a lame joke), maybe it's the display driver?

But no, that's ridiculous, gpsp can run F-Zero at much higher speeds

Hayleia · « **Reply #5 on:** June 27, 2014, 09:02:07 am »

Now that I think of it, which version of Jetpack Impossible did you use to do your tests ? Because there was one ridiculously slow version (using double buffering) that was attached to a post by Matref in that topic, but the version I said could possibly use fast routines was the one you can find in the TI Planet archives that this post links to.

aeTIos · « **Reply #6 on:** June 27, 2014, 09:16:19 am »

Oh. I used the slow version. I wish I never found the fast version

j/k.

So disregard what I said above about "proven wrong", the version Hayleia linked here is quite a bit faster. Holy Cow.

Streetwalrus · « **Reply #7 on:** June 27, 2014, 10:36:48 am »

Code: [Select]

                    │16:22:32       &aeTIos | void set_display_buffer(void* buffer)                                                                                                         │
                    │16:22:32       &aeTIos | { *(volatile void**)0xC0000010 = buffer;                                                                                                      │
                    │16:22:32       &aeTIos | }                                                                                                                                             │
                    │16:22:32       &aeTIos | void update_at_vblank()                                                                                                                       │
                    │16:22:32       &aeTIos | { while((*(volatile unsigned*)0xC0000020 & 4) == 0) { } *(volatile unsigned*)0xC0000028 = 4; set_display_buffer(nspire_displayed_screen);     │
                    │16:22:41       &aeTIos | }

He dug that in the gpSP source, I think it might be useful. Basically buffer swapping.

Hayleia · « **Reply #8 on:** June 27, 2014, 11:22:06 am »

Well matref and pierrot already tried to that but for some reason it was slow too -.-

Matrefeytontias · « **Reply #9 on:** June 27, 2014, 12:45:09 pm »

Quote from: Vogtinator on June 27, 2014, 08:09:52 am

So you don't handle those different LCDs differently? Using the monochrome LCD in 16bpp mode like a color one looks awful.

yeah well you could avoid these useless comments. I do that because it's faster since you're not required to test if the screens are different. And the problem right now is that it's 3 times slower on the color calcs than on the monochrome calcs, so using the monochrome LCD in 16 bpp mode is apparently a good idea.

Quote from: aeTIos on June 27, 2014, 08:40:34 am

I've run a few tests and I'm fairly sure it's n2DLibs sprite drawing function.

I already sent you a binary where no sprites were drawn, and you told me the speed was the same.

Quote from: aeTIos on June 27, 2014, 08:40:34 am

I already did test IkarugaX for you, and the time-to-scroll-sprite-over-screen time is almost the same, namely 06:55 seconds. When I take away the fullscreen pic on the background, it's suddenly three times as fast: 01:91 seconds.

*nKaruga

Well that's kinda strange because that's supposed to be super-fast, as it's barely slower than just clearing the screen - except if accessing arrays is really that slow.

Quote from: Hayleia on June 27, 2014, 11:22:06 am

Well matref and pierrot already tried to that but for some reason it was slow too -.-

Mh, I never tested bit 2 of the LCD driver. I'll try that.

Vogtinator · « **Reply #10 on:** June 27, 2014, 02:58:38 pm »

Could you do something entirely without n2dlib, just directly memcpy one buffer into the other 500 times and compare that? Both LCDs in 16bpp mode of course.

Matrefeytontias · « **Reply #11 on:** June 27, 2014, 03:45:17 pm »

So you mean copying a buffer 500 times to the screen, and comparing that with copying 500 times a buffer in another buffer ?

Vogtinator · « **Reply #12 on:** June 27, 2014, 03:46:15 pm »

No, run the program on CX and not-CX.

Matrefeytontias · « **Reply #13 on:** June 27, 2014, 04:15:07 pm »

Quote from: Matrefeytontias on June 26, 2014, 06:25:50 am

Also, I have no color calc to test, only monochrome.

Streetwalrus · « **Reply #14 on:** June 27, 2014, 04:17:03 pm »

Also you have plenty of color calc owner to test it for you. Just give the thingy to us.

Author Topic: [Ndless] Help with bottleneck on color calcs only (Read 17487 times)

Matrefeytontias

[Ndless] Help with bottleneck on color calcs only

Vogtinator

Re: [Ndless] Help with bottleneck on color calcs only

Matrefeytontias

Re: [Ndless] Help with bottleneck on color calcs only

Vogtinator

Re: [Ndless] Help with bottleneck on color calcs only

aeTIos

Re: [Ndless] Help with bottleneck on color calcs only

Hayleia

Re: [Ndless] Help with bottleneck on color calcs only

aeTIos

Re: [Ndless] Help with bottleneck on color calcs only

Streetwalrus

Re: [Ndless] Help with bottleneck on color calcs only

Hayleia

Re: [Ndless] Help with bottleneck on color calcs only

Matrefeytontias

Re: [Ndless] Help with bottleneck on color calcs only

Vogtinator

Re: [Ndless] Help with bottleneck on color calcs only

Matrefeytontias

Re: [Ndless] Help with bottleneck on color calcs only

Vogtinator

Re: [Ndless] Help with bottleneck on color calcs only

Matrefeytontias

Re: [Ndless] Help with bottleneck on color calcs only

Streetwalrus

Re: [Ndless] Help with bottleneck on color calcs only