nKaruga, PC demake of Ikaruga (ported from TI-Nspire)

[matrefeytontias]

Bump,

So I ran tests to see which of the two updateScreen() routines were faster, turns out that the memcpy version slows down the game by 5 FPS when uncapped (110 vs 115) compared to my own (now reworked) version.

Code Select Expand


void updateScreen()
{
int di;
void *pixels;
void *buf = BUFF_BASE_ADDRESS; // cast to void*
int pitch;
SDL_LockTexture(MAIN_SCREEN, NULL, &pixels, &pitch);
for (di = 0; di < 320 * 240 * sizeof(unsigned short); di += sizeof(unsigned int))
*(unsigned int*)(pixels + di) = *(unsigned int*)(buf + di);
SDL_UnlockTexture(MAIN_SCREEN);
SDL_RenderCopy(sdlRenderer, MAIN_SCREEN, NULL, NULL);
SDL_RenderPresent(sdlRenderer);
updateKeys();
}


[gameblabla]

Interesting, thanks matref for testing.
I tried it on my fork and memcpy was actually faster.
Max FPS was 305 and Min FPS was 300 on level 1.

Using this instead :

Code Select Expand

for (i = 0; i < 76800; i++)
*(unsigned short*)(pixels + i * 2) = BUFF_BASE_ADDRESS[i];

Max FPS now is 303 and min FPS is 298 on level 1.

I'm running this on an AMD FX 6350.
Either memcpy is faster for small copies (matref has to copy a bigger buffer) or it scales better at higher framerates.

But overall, it was roughtly the same, no huge difference.

[matrefeytontias]

Wait, you got nKaruga running at 300 FPS ? How even is that possible ? It shouldn't be.

Also, you should try the code I posted above.

[Yuki]

Hey there, I'm trying to make it work on my macOS Sierra machine, just to see if it works... Seems Apple LLVM is choking on a particular error only GCC allows as an extension, you might want to check it out.

src/n2DLib.c:78:28: error: arithmetic on a pointer to void
                        *(unsigned int*)(pixels + j * pitch * 2 + i * 4) = c;
                                         ~~~~~~ ^
src/n2DLib.c:79:28: error: arithmetic on a pointer to void
                        *(unsigned int*)(pixels + (j * 2 + 1) * pitch + ...
                                         ~~~~~~ ^

I'll run a few more tests, including installing an actual copy of GCC, and I'll report back and even send some pull requests.

[matrefeytontias]

Yeah, GCC allows that with -fpermissive, and I find it useful and practical so I use it. Thanks for trying.

[novenary]

The problem here is that you shouldn't manipulate void pointers in the first place. If you want a pointer to bytes, use uint8_t from stdint.h, or char. A properly typed pointer won't throw that error.

[Yuki]

Yeah, it works if I cherrypick this commit. Anyway, look at my fork, commited some useful stuff for Mac (make mac should work, at least with that commit), next I'll try to make deploy-mac into an .app.

[matrefeytontias]

Alright, yesterday I found why it was crashing when toggling fullscreen, turns out it's an actual bug with the SDL2 Direct3D renderer. That's fixed now, so you'll be able to press F to toggle between windowed and fullscreen mode.

[Dream of Omnimaga]

Something I am curious about is what are the minimum system requirements. For example, would the game run on @Jkolade936 PC from 1989?

[matrefeytontias]

Well I don't know. Since I'm going the "all software rendering" route, it's probably not going to be very efficient, but I guess one's gotta try.

[Dream of Omnimaga]

Actually I meant 1998, not 1989, but yeah I was wondering since certain users are stuck on extremely old hardware. In my case the game obviously runs with no problem on my 2009 PC but it's an i7, so...

[gameblabla]

Something I am curious about is what are the minimum system requirements. For example, would the game run on @Jkolade936 PC from 1989?

Matref's version has much higher requirements, despite it being based on the Ti-Nspire port.
That's because software rendering on SDL2 is very slow... much slower than its predecessor, SDL 1.2.
Even a GCW0 with its 1Ghz MIPS32r2 cpu cannot run this game smoothly...
So yeah, it requires at least a Pentium III 1.4Ghz and a decent GPU.

Speaking of which, i spent 4 days trying to switch to textures.
The game runs much faster (1600 Fps versus 300 Fps) and rotations also look nicer now.

Here's my fork :
[spoiler][/spoiler]
And here is matref's version using the software renderer :
[spoiler][/spoiler]

Unfortunely, i couldn't implement everything and i have encountered lots of bugs so i had to introduce lots of ugly hacks.
The font looks different, the background's scrolling is different, enemies flashes black (due to SDL's blending support not working properly)
and the rotations are not quite accurate...

This version should work on better on older pcs with a somewhat ok gpu tho.
Here are the download links (i fixed the Linux version too btw) :
https://gameblabla.nl/files/nkaruga/nKaruga-xenial-amd64.deb
https://gameblabla.nl/files/nkaruga/nKaruga-windows-x86.zip

[matrefeytontias]

I quickly looked at it and yeah, that's a handful of really horrible hacks you've put together >_>

I didn't know software rendering was that slow with SDL2. Since I'm constantly capping at 60 FPS on my machine I didn't notice, and I assumed it would be fine since the game did run completely fine on the TI-Nspire (so it's really not how I do things). That makes me think that I should eventually use a HARDWARE_RENDER define and rewrite a new version of n2DLib that uses SDL2's HW rendering capabilities when that define is ... well, defined.

Also, I haven't tried, but your implementation of drawDecimal is supposed to break (https://github.com/gameblabla/nKaruga/blob/newn2dlib/n2dlib/SDL2/n2DLib.c#L505). It's an int we're talking about, it can have up to 10 digits, not 6 (11 counting the minus sign).

Also, your rotations only look better because SDL2 renders them on a 640x480 window, when n2DLib does it on a 320x240 buffer. If you look closely in your screenshot, you can see that the rotations use what should technically be sub-pixel measures, but isn't because of the scaling up.

So yeah, as I said, it kind of defeats the whole point of me making the game but I will provide a flag to enable hardware rendering eventually. That will also permit me to rewrite hardware rendering with a better understanding of the existing code, thus resulting in a cleaner result (supposedly). I'm not saying I'll be doing this anytime soon (probably after I'm done with it, since it's mostly just changing the way images are loaded and rewriting most of n2DLib's drawing functions), but it will happen.

[Dream of Omnimaga]

To be honest, while gameblabla's screenshot look nicer, matref's look more accurate in terms of the 320*240 resolution. It depends of if you're going for hardcore oldschoolness or Super Mario Maker fake retro style I guess

[gameblabla]

I didn't know software rendering was that slow with SDL2. Since I'm constantly capping at 60 FPS on my machine I didn't notice, and I assumed it would be fine since the game did run completely fine on the TI-Nspire (so it's really not how I do things). That makes me think that I should eventually use a HARDWARE_RENDER define and rewrite a new version of n2DLib that uses SDL2's HW rendering capabilities when that define is ... well, defined.

I can still confirm software rendering on SDL2 is really slow as i actually made some tests.
Switching your version to SDL 1.2 now gets me a maximum framerate of 380 FPS instead of 300.
On the GCW0, i went from 35 FPS to nearly the double of that. (with some tweaking)

Anyway, i added a SDL 1.2 software renderer based on your version and the game now runs fullspeed on the GCW0 !
https://www.youtube.com/watch?v=SgYq9c3b9U4
I forgot to mention it but users can put custom songs in the home folder and nKaruga will play them instead of its own
as the video demonstrates it.

So now i can finally sit back, be a lazy man and let you work on it.