First of all in the engine there are a few hardcoded values that you have to live with, that's what allows good optimization. Look at the macros in the header and see if you have to change them (you should only need to change M7_NUM_TEX IIRC). A texture in the engine is a 16x16 bitmap, aka a tile. m7_LoadTex() adds M7_NUM_TEX 16x16 SDL_Surfaces to the main texture array that contains all of the tiles. Look at the demo I wrote, start from there and modify it bit by bit so you understand what you and the code are doing.

Also this line's wrong: tex[k][j] = nSDL_GetPixel(src, j, i * M7_TEX_SIZE + k); nSDL_GetPixel() takes x- and y-coordinates as input. But you shouldn't even have to write such a function, as m7_LoadTex() does just that (look at how it was done in the demo).

Greetings from a public library in Canberra.

I'd actually suggest you use t0xic_kitt3n's mode7 engine that I modified for 8-bit nSDL. It's been optimized to hell, uses tiles and is easily configurable and uses the native rendering resolution. http://www.omnimaga.org/index.php?topic=15526.msg282877#msg282877

This'll be my final update (plane leaving for Australia tomorrow).

Changes:
- Performance (oncalc): 100 FPS on Touchpad, most probably ~50 FPS on CX (can't test it, lil' brother lost his calc)
- Separated the mode7 part more and renamed stuff for more consistency (resembles much more like an engine)
- Fixed some issue with positions on the map being wrong
- Added a simple function to load textures (only works with 8-bit surfaces, i.e. surface has to be converted first if necessary)
- Cleaned up stuff

Code & binary attached.

EDIT:
One thing I've noticed is that accessing global variables is much slower than accessing any other type of variable. Just using the global screen SDL_Surface in the rendering function decreased the framerate by nearly 10 FPS! It might be good to know if speed is of your concern. IIRC it also applied to accessing structure items.

As said above.

Here's the post: http://www.omnimaga.org/index.php?topic=12378.msg253986;topicseen#new

Good news!

I've now added real color support and with "real" textures! I removed the plain color/texture division and used the whole byte as a palette index (i.e., 8-bit, 256 colors). It was the best method speed/simplicity/size-wise.

After some nitpicky optimization, I managed to push the framerate to 90+ FPS on Touchpad/Clickpad, and to a constant 45 FPS on CX! I believe it's soon pretty much the theoretical maximum performance you can expect.

Aaaand a screenshot because everyone loves 'em:



Source code and binary attached!

When using 8 bpp (when initializing SDL with 8 bpp) it's palettized (every color mapped to a certain RGB value; palette is located in screen->format->palette and can be changed using SDL_SetColors()). It generates some default palette which is the one I used.
When using 16 bpp, colors are just encoded as 16-bit high color.

Good news, I managed to push to a constant 40 FPS on CX, and over 70 FPS (!!) on Touchpad.

Can't remember to be honest, it was some key combination to display two pages at once.

ALRIGHTY. I've tracked down one major bottleneck in nSDL. It was quite obvious but I never thought it would be such a slow-down. Calling any function that pumps the events (SDL_PollEvent(), SDL_GetKeyState(), whatever) seriously hurts performance in speed-critical code. Nothing can really be done about it, just don't use those functions where you need speed, instead stick to keyIsPressed() and whatnot (as most people have done so far in fact).

I changed all the in-game SDL event handling code to normal ndless-style key handling, and now the game jumped to nearly 60 FPS! It's a massive improvement. I was myself already quite impressed with what we had before, updating the whole screen and having multiple layers and everything, but I never expected that I could nearly double the framerate!

Here's a video so you can see, it's much more of a shoot em up now (you can see the framerate in the last part of the video):

<a href="http://www.youtube.com/watch?v=PViYGm9jJ3A" target="_blank">http://www.youtube.com/watch?v=PViYGm9jJ3A</a>

DOWNLOAD ATTACHED.

Thanks a lot! That's some pretty damn clean code, it's a pleasure to read/mess with.

EDIT:
Purely for viewing pleasure, a CX color version:


And some on-calc footage to see how it runs:
<a href="http://www.youtube.com/watch?v=HUwTQSwcA70" target="_blank">http://www.youtube.com/watch?v=HUwTQSwcA70</a>

(I edited a few lines to get it working with nSDL and got about 6 FPS extra at the same time)

It runs at a rather constant 28-31 FPS on CX (could certainly be pushed further if it was optimized for 16 bpp) and 45-47 FPS on Touchpad when the whole lower half of the screen is filled.

EDIT2: I added the TNS if somebody wants to play with it.

Tiny update after a long pause.

Changes:
- Compiled with nSDL 1.1.1
- Changed background
- Added FPS counter (toggle with the I-key)
- Uhh... that's it

It runs at 30-40 FPS on CX, 50-60 FPS on Touchpad (but don't even bother with that one, the LCD is such a piece of shit it's only an ugly blurry mess). I haven't even bothered to optimize whatsoever.

Also a gameplay video:
EDIT: Check out the one below for a newer one

Source code available here.

Download attached.

I added an image to NTI converter: http://hoffa.franceserv.fr/nti/

Oh wow, well I'm glad I found out about this before leaving. There was one big issue with 1.1.0; I'll quote:


Let's just pretend that 1.1.0 never existed.

Anyway, updated, download available on the website, you know the drill.

EDIT:

Oh, by the way, I also wrote an online image-to-NTI converter. It does exactly the same thing as the program included in nSDL, except it's faster for massive images and does no formatting whatsoever (which means a smaller source file): http://hoffa.franceserv.fr/nti/

Awesome!

BTW, about the SDL_GetTicks() issue you mentioned earlier, it was my fault. I had completely forgotten to uncomment a line in nSDL that enabled bus access for the timer, and consequently it worked on the emulator but not one the actual hardware (i.e., it returned always 0). It was extremely dumb and careless from me, but I've updated it now, SDL_GetTicks() should work now (I've tested it on both calculators, everything runs smoothly).

Maybe, but I doubt it is faster. Many of the libraries use very clever hacks, such as this one that even uses ARM assembly.