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

[gameblabla]

@gameblabla : I'm not having any scaling issue, I don't want fullscreen at all, just a borderless window. And yes, I did hardcode 640x480 in it. If you want to make it work with 320x240, you'll have to modify updateScreen.

So having a 640x480 borderless window right in the middle is what you want ?
For me, the fullscreen mode makes it so much better and it's more confortable to play than how it currently is.
I think everyone here will agree with me.

Or you can make it resizable and get the window's resolution with SDL_GetWindowSize

I'm not "stuck" with software rendering, that's a choice I'm making. I'll remind you that I started this project nearly from scratch (except for HW interfaces and sounds) in order to reinvent the wheel and get better at programming. I'm also doing a demake ; I'm willingly not using hardware acceleration. I know SDL2 provides that, but that's not the point of me making that game.

That's strange but if that's for learning purpose i will not stop you.

[matrefeytontias]

Yeah it is what I want. I guess I can give it a border so that it can be moved around, but I don't want it to be resizable. Also, fullscreen makes it look ugly, because the pixels get waaay too big.

[gameblabla]

Hmm; i guess i'll fork your game just so i can have fullscreen joy.

[matrefeytontias]

Well you're gonna fork it anyway, so feel free to do whatever you want with it and tell me how it looks. I haven't tried making it fullscreen for a while now (last time was before I switched from SDL 1.2 to SDL2), so if you could somehow show me how it looks, that'd be cool.

[Dream of Omnimaga]

The ability to scale the window up/down would be nice (provided that the sprites scaling uses nearest neighbor rather than ugly blurring), because on a 4K monitor the game window is very small (it's fine on 1920x1080, though)

Also the funny thing is that I think a CE port would have run at half the frame rate at worst if it didn't require much RAM, because the CE LCD is so much faster than the Nspire CX LCD that it would probably have offset the much inferior CPU speed. However I think instead of a CE port it would be better if someone made a brand new game adapted for that calc.

[gameblabla]

Well you're gonna fork it anyway, so feel free to do whatever you want with it and tell me how it looks. I haven't tried making it fullscreen for a while now (last time was before I switched from SDL 1.2 to SDL2), so if you could somehow show me how it looks, that'd be cool.

Here how it looks like fullscreen :
https://gameblabla.nl/img/nkaruga_fullscreen.png
And how it looks like with aspect ratio correction :
https://gameblabla.nl/img/nkaruga_fixedratio.png

Btw guys, i have worked on my fork and i did several things.

• Reduced the screen resolution to 320x240 and sped up copying (memcpy)
• It's also fullscreen
• Changed the controls
• Added support for the home folder, meaning it has better linux support
• Simplified the Makefiles (i do not like what Matref did with those)

Btw, matref's game is a lot more playable on PC.
I have released binaries for Ubuntu Xenial (deb) and Windows.
https://gameblabla.nl/files/nkaruga/nKaruga-xenial-amd64.deb
https://gameblabla.nl/files/nkaruga/nKaruga-windows-x86.zip

Hopefully when you will try it, you will change matref's mind

fork's repo is here : https://github.com/gameblabla/nKaruga

[matrefeytontias]

You're missing a whole lot of points with your changes. First, I want to be able to work on the game without sudo rights, so I must include SDL binaries and includes because I can't install SDL2-dev. Second, I also want to be able to distribute the game to machines without sudo rights, so that means no package (I could make one for those with sudo rights, but meh). For the record, I did try to run your Debian package on my system, it didn't work because you didn't include the SO for SDL2, hence why I did. Changing the default controls are useless and annoying, since it's originally up to my preference to have that (I did include a "configure controls" option for that purpose) and now merging the actually useful parts of your work will force me to include and then revert that part. Same thing about the makefiles, maybe you don't like it, but it's still my project and I made it work for my environment (you'll notice that it also works on every other environment, while your method won't work in mine).

Also, memcpy is slower than the way I did it because I'm copying unsigned ints and memcpy is copying chars, resulting in 4 times more RAM assignations (registers are indeed at least 32 bits). Reducing the resolution to 320x240 is indeed a good call, but not to make it fullscreen. I stand by my opinion that the game looks bad when scaled up too much, especially because that low resolution makes for huge pixels, and I would rather have SDL2 materially scale it to an adequate size (still 640x480 for me). I can still include a "fullscreen" key anyway, for those who really want it.

Basically all of your changes are irrelevant, except for maybe the home folder, which you'll have to tell me about. Being very not used to Linux, what are its uses ? What does it do, and why does nKaruga need it ?

[gameblabla]

lol matref, so much anger. I did not even need to troll you, just to fork your repo and remove all you did lol.

For the record, I did try to run your Debian package on my system, it didn't work because you didn't include the SO for SDL2, hence why I did

Yeah; the package only works on Ubuntu 16.04 Xenial.
What you're doing is basically to static link libSDL2 to your game, which improves compatilibity but you are doing so by using pre-compiled package,
which annoys the hell out of me lol.
I think it might be better to just use gitsubmodules for SDL2 and SDL2_mixer.

Changing the default controls are useless and annoying, since it's originally up to my preference to have that (I did include a "configure controls" option for that purpose) and now merging the actually useful parts of your work will force me to include and then revert that part.

I agree but the default controls were for the GCW0 and the controls are mapped like this.
Plus, i find it a very odd you use I,O,P for all your buttons, its un-confortable (but at least you can customise them)

Also, memcpy is slower than the way I did it because I'm copying unsigned ints and memcpy is copying chars, resulting in 4 times more RAM assignations (registers are indeed at least 32 bits).

I need to gperf the hell of out it or write a benchmark just to see if this is true indeed. (i understand mempcy only copies chars but despite, does it mean it's still slower than what you did ?)

I stand by my opinion that the game looks bad when scaled up too much, especially because that low resolution makes for huge pixels, and I would rather have SDL2 materially scale it to an adequate size (still 640x480 for me). I can still include a "fullscreen" key anyway, for those who really want it.

I never saw someone as adamant as you as far as pixel-perfect is concerned.
You should still include a fullscreen and put the borders

Same thing about the makefiles, maybe you don't like it, but it's still my project and I made it work for my environment (you'll notice that it also works on every other environment, while your method won't work in mine).

What's your OS ? Windows ?
Yeah, i understand my method will not work very well on it...
On ubuntu, 32-bits and 64-bits lib and headers are seperated so that makes it a lot easier
to manage 32-bits/64-bits things.

except for maybe the home folder, which you'll have to tell me about. Being very not used to Linux, what are its uses ? What does it do, and why does nKaruga need it ?

Putting the config file in the home folder is useful because when you distribute it in a deb package, you can't write to the root directory.
So one way to workaround this is to get the home directory with getenv (or in this case, XDG_CONFIG_HOME), which is generally $HOME/.config.
So get the environment variable XDG_CONFIG_HOME, create a directory called .nkaruga and place your config file there.
If you don't do that, the game will fail to write the directory, since the directory its going to write to is read-only and write protected.
Look at what i did for the main.cpp file :
https://github.com/gameblabla/nKaruga/commit/cd75fb479adcf169ef33d9bd587b84c8059a2d02

i think i miss but you ate me matref.
You ate me.

[matrefeytontias]

lol matref, so much anger. I did not even need to troll you, just to fork your repo and remove all you did lol.

So funny and relevant to the discussion. Thanks for helping nKaruga grow into a good game by the way.

For the record, I did try to run your Debian package on my system, it didn't work because you didn't include the SO for SDL2, hence why I did

Yeah; the package only works on Ubuntu 16.04 Xenial.
What you're doing is basically to static link libSDL2 to your game, which improves compatilibity but you are doing so by using pre-compiled package,
which annoys the hell out of me lol.
I think it might be better to just use gitsubmodules for SDL2 and SDL2_mixer.

Again, I need to be able to work on the game in a non-sudo environment, and I set all of that up in a way that allows me (and everybody else) to do so. You don't like it ? Well it works, and your method doesn't, what more can I say.

Changing the default controls are useless and annoying, since it's originally up to my preference to have that (I did include a "configure controls" option for that purpose) and now merging the actually useful parts of your work will force me to include and then revert that part.

I agree but the default controls were for the GCW0 and the controls are mapped like this.
Plus, i find it a very odd you use I,O,P for all your buttons, its un-confortable (but at least you can customise them)

That's fair enough, but if it's really for the GCW0, then make a different target, don't change the overall defaults. I'm fully okay with incorporating a new target to the build, but don't change unimportant stuff like that. I chose I, O, P because it felt right under my hand when I'm using ZQSD/WASD for movement. I know it's personal preference, but I wrote the game so I'm allowed.

Also, memcpy is slower than the way I did it because I'm copying unsigned ints and memcpy is copying chars, resulting in 4 times more RAM assignations (registers are indeed at least 32 bits).

I need to gperf the hell of out it or write a benchmark just to see if this is true indeed. (i understand mempcy only copies chars but despite, does it mean it's still slower than what you did ?)

Well no, you should have gperf'd it before that commit saying you made it faster.

I stand by my opinion that the game looks bad when scaled up too much, especially because that low resolution makes for huge pixels, and I would rather have SDL2 materially scale it to an adequate size (still 640x480 for me). I can still include a "fullscreen" key anyway, for those who really want it.

I never saw someone as adamant as you as far as pixel-perfect is concerned.
You should still include a fullscreen and put the borders

I mean it's not about being pixel-perfect, it's about looking good. Yes, I am adamant on having my game look good, and in my opinion, when an in-game pixel takes up a 8*8 square of on-screen pixels, it's ugly. I'll definitely put the option for fullscreen though - and keep the correct aspect ratio of course.

Same thing about the makefiles, maybe you don't like it, but it's still my project and I made it work for my environment (you'll notice that it also works on every other environment, while your method won't work in mine).

What's your OS ? Windows ?
Yeah, i understand my method will not work very well on it...
On ubuntu, 32-bits and 64-bits lib and headers are seperated so that makes it a lot easier
to manage 32-bits/64-bits things.

I work on Windows 8.1, KDE 64-bits (school machines) and Ubuntu 32-bits (in a VM).

except for maybe the home folder, which you'll have to tell me about. Being very not used to Linux, what are its uses ? What does it do, and why does nKaruga need it ?

Putting the config file in the home folder is useful because when you distribute it in a deb package, you can't write to the root directory.
So one way to workaround this is to get the home directory with getenv (or in this case, XDG_CONFIG_HOME), which is generally $HOME/.config.
So get the environment variable XDG_CONFIG_HOME, create a directory called .nkaruga and place your config file there.
If you don't do that, the game will fail to write the directory, since the directory its going to write to is read-only and write protected.
Look at what i did for the main.cpp file :
https://github.com/gameblabla/nKaruga/commit/cd75fb479adcf169ef33d9bd587b84c8059a2d02

Well again, I'm targetting non-sudo environments, hence why I included all that rpath work in the linking process, that's so everything works from the executable's folder, regardless of any admin rights. That means this is irrelevant once again, since the game's directory can only be stored somewhere with write access anyway, since it won't request admin rights. There's still the possibility that someone will manually copy it to somewhere elevated, but I don't pretend to make the game idiot-proof.

i think i miss but you ate me matref.
You ate me.

... what ?

[Dream of Omnimaga]

, when an in-game pixel takes up a 8*8 square of on-screen pixels, it's ugly.

By your logic, every single console game released before the Gamecube era is ugly

[matrefeytontias]

In the case of this game only. And 8*8 is a rough estimate.

EDIT : to be fair, it's not that it's "ugly", it's just not what I want this game to look like.

[Dream of Omnimaga]

Ah ok. Well I felt the game had that retro feel actually.

[matrefeytontias]

Alright, I came back home and I tried the fullscreen version (basically just used the SDL_WINDOW_FULLSCREEN flag in SDL_CreateWindow), and actually it's not that bad. I may have made a big fuss about not much. Although I'm curious, @gameblabla in your version of n2DLib.c you're using SDL_WINDOW_FULLSCREEN_DESKTOP, which on my PC makes the game window fill the entire desktop screen by stretching it. Any reason why you're using that ?

EDIT : oh. Apparently alt-tabbing out of the fullscreen window and alt-tabbing back to it crashes it with a segfault. Not sure what's doing that, it didn't do that without fullscreen.

[gameblabla]

Well no, you should have gperf'd it before that commit saying you made it faster.

It's still under the wip branch and i had not merged yet so it's okay.

That's fair enough, but if it's really for the GCW0, then make a different target, don't change the overall defaults. I'm fully okay with incorporating a new target to the build, but don't change unimportant stuff like that. I chose I, O, P because it felt right under my hand when I'm using ZQSD/WASD for movement. I know it's personal preference, but I wrote the game so I'm allowed.

How about using CTRL/ALT/... controls only when arrow keys are being used then ?

I mean it's not about being pixel-perfect, it's about looking good. Yes, I am adamant on having my game look good, and in my opinion, when an in-game pixel takes up a 8*8 square of on-screen pixels, it's ugly. I'll definitely put the option for fullscreen though - and keep the correct aspect ratio of course.

Thanks for considering this.

I work on Windows 8.1, KDE 64-bits (school machines) and Ubuntu 32-bits (in a VM).

It makes all sense now !

Well again, I'm targetting non-sudo environments, hence why I included all that rpath work in the linking process, that's so everything works from the executable's folder, regardless of any admin rights. That means this is irrelevant once again, since the game's directory can only be stored somewhere with write access anyway, since it won't request admin rights. There's still the possibility that someone will manually copy it to somewhere elevated, but I don't pretend to make the game idiot-proof.

But in any case matref, it will still work in a non-sudo environment.
Plus, you get to have your nice icon that appears in your desktop, it just makes it so much nicer and... professional.

Alright, I came back home and I tried the fullscreen version (basically just used the SDL_WINDOW_FULLSCREEN flag in SDL_CreateWindow), and actually it's not that bad. I may have made a big fuss about not much. Although I'm curious, @gameblabla in your version of n2DLib.c you're using SDL_WINDOW_FULLSCREEN_DESKTOP, which on my PC makes the game window fill the entire desktop screen by stretching it. Any reason why you're using that ?

Because that's what i wanted to do, have my screen filled with your game.
Plus, you don't have to detect your window's detection and resize manually.
In my case though, i modified n2DLib so it uses SDL2 aspect ratio correction instead.
It looks like this on mah monitor :
https://gameblabla.nl/img/nkaruga_fixedratio.png

EDIT : oh. Apparently alt-tabbing out of the fullscreen window and alt-tabbing back to it crashes it with a segfault. Not sure what's doing that, it didn't do that without fullscreen.

Hmm... It doesn't do that on my desktop, you might want to investigate using gdb.

Btw, i forgot to tell you that i found some bugs, namely uninitialised variables in BulletArray after line 404 :

Code Select Expand


void BulletArray::clear()
{
for(int i = 0; i < bulletCount; i++)
data[i].deactivate();
for(int i = 0; i < fragmentCount; i++)
data_fragment[i].deactivate();
for(int i = 0; i < homingCount; i++)
data_homing[i].deactivate();
bulletCount = 0;
fragmentCount = 0;
homingCount = 0;
}

bulletCount, fragmentCount, homingCount are not initialised properly so sometimes, they can crash the loop and it will result in a buffer overflow.
I replaced them with MAX_BULLET, MAX_FRAGMENT and MAX_HOMING but i don't think that's correct...
I'll make a github issue about it and leave this thread all alone.

[matrefeytontias]

That's fair enough, but if it's really for the GCW0, then make a different target, don't change the overall defaults. I'm fully okay with incorporating a new target to the build, but don't change unimportant stuff like that. I chose I, O, P because it felt right under my hand when I'm using ZQSD/WASD for movement. I know it's personal preference, but I wrote the game so I'm allowed.

How about using CTRL/ALT/... controls only when arrow keys are being used then ?

I'd rather just have the people configure their own keys as they want. It's just selecting a menu option and pushing 4 keys.

Well again, I'm targetting non-sudo environments, hence why I included all that rpath work in the linking process, that's so everything works from the executable's folder, regardless of any admin rights. That means this is irrelevant once again, since the game's directory can only be stored somewhere with write access anyway, since it won't request admin rights. There's still the possibility that someone will manually copy it to somewhere elevated, but I don't pretend to make the game idiot-proof.

But in any case matref, it will still work in a non-sudo environment.
Plus, you get to have your nice icon that appears in your desktop, it just makes it so much nicer and... professional.

Nope, I tried on my KDE school machines and I couldn't build or run the game because I needed SDL2 and SDL2_mixer on them, which do need admin rights to be installed (apt-get) or built (make install). Same goes for Windows target and the various DLLs ; either you have it in the same directory (which requires some extra rpath work on Linux) or you have it installed locally, which in all cases requires admin rights.
I agree that having a nice icon and stuff is much more professional, but for the reasons I told you I doubt that's going to happen.

Alright, I came back home and I tried the fullscreen version (basically just used the SDL_WINDOW_FULLSCREEN flag in SDL_CreateWindow), and actually it's not that bad. I may have made a big fuss about not much. Although I'm curious, @gameblabla in your version of n2DLib.c you're using SDL_WINDOW_FULLSCREEN_DESKTOP, which on my PC makes the game window fill the entire desktop screen by stretching it. Any reason why you're using that ?

Because that's what i wanted to do, have my screen filled with your game.
Plus, you don't have to detect your window's detection and resize manually.
In my case though, i modified n2DLib so it uses SDL2 aspect ratio correction instead.
It looks like this on mah monitor :
https://gameblabla.nl/img/nkaruga_fixedratio.png

Weird, that's the look I get when I use SDL_WINDOW_FULLSCREEN, not SDL_WINDOW_FULLSCREEN_DESKTOP. When I use the latter, I don't get any letterbox, just the full, stretched window that doesn't hold the original aspect ratio, but I guess that's because I'm not using SDL_RenderSetLogicalSize. It works either way, but I guess I'll end up using that regardless because I will indeed shrink the window size back to its original 320x240 and let SDL2 handle the scaling, be it with fullscreen or not.