CodeWalrus

TODO : write this when the PC port is 100% fixed and to the level of the Nspire version

[spoiler](https://www.getdigital.fr/web/getdigital/gfx/products/__generated__resized/380x380/Aufkleber_Trollface.jpg)[/spoiler]

The entire game now just shows a Trollface O.O?

Just kidding, I would be very interested into playing a nKaruga version for PC. Will music (if any) have a retro feel like Sega Mega Drive? Also will graphics remain the same, scaled up for those who wants to play Full screen?

Good luck! (Also I am cloning this topic in the non-calc section so it shows in both :walrii: )

All of the graphics (and the UI) will remain the same. Actually, the screen itself will still be 320x240, but scaled up twice so that it shows pixels and stuff, just like a retro console would :)

Awesome to hear. And yeah I noticed. I am amazed so far by the result and there is a news coming up. Some suggestions :)

-Key detection on title screen options is quite laggy. Sometimes it won't respond then it registers keypresses twice. It's perfectly fine inside the game
-Some text seems a bit cut off. For example the 1 digit misses some outlines at the top. Is that normal?
-An option to play at 1x, 3x, 4x or 5x scaling would be nice for people with different resolutions, perhaps also with an option to maximize the window while still having the game in the center with a black frame. That way we can play close to how we play SNES/NES emulator games :)
-Music, but it would need to sound old school or like video game stuff. Not necessarily chiptune-like but at least limited or with some electronic sounds. Maybe covers of my songs? :P

<yeah I posted a demo on IRC>

- the way I did it in the menus is just reducing the framerate to 10 FPS :P I was basically being a lazy ass, of course I'll switch to proper key-repeat handling in the (near) future.
- it appears that it's just because it reached the top of the window, thus having a line of pixels outside the screen. I'll fix that eventually.
- honestly, 1x is super tiny and over 3x is super huge ... I mean, the window is always a multiple of 320x240, so it gets insanely huge pretty fast. I'll eventually add a full-screen mode though, just to see what it looks like.
- Yeah well that's planned, but won't come anytime soon :P

Aah I see now. Reducing menu frame rate is definitively a good way to save on computer resources. ANd I see about the text.

As for 1x, it's more if for example someone has a small resolution on a very old computer, so it's not really that necessary. But 3x and 4x would be nice to have because on my 1920x1080 screen, 640x480 is very small. 4x would make it 1440x960 IIRC. Even 4x would be small on 4K. If you add a full screen mode, though, keep in mind that some video cards blurs images at low resolution.


Do you plan to put the demo and screenshots in the first post?

4x is 1280x960 actually. But yeah, I see your point, I'll implement that then.

Download the game on GameJolt : http://gamejolt.com/games/nkaruga-2d-ikaruga-demake/92026

Don't forget to read the instructions !

Is it an update of the demo you posted on IRC? Just wondering in case I need to update.

EDIT: Aw, shame that your Gamejolt description makes absolutely zero mention of TI calculators :(

Matref, there's a reason why things like SDL2 or SDL_gfx exists :
Use them for screen scaling !

For SDL_gfx, it works like this :
You detect the resolution with SDL_GetVideoInfo.
You store the detected resolution somewhere and you tell SDL_SetVideoMode to take all the screen.
Next, you create a RGB Surface with the game's native resolution.
Make sure that your game draws to the RGB Surface instead of the screen.

That's how i do it (the game's native resolution here is 320x240) :

#ifdef SCALING
const SDL_VideoInfo* info = SDL_GetVideoInfo();
scale_w = info->current_w / 320;
scale_h = info->current_h / 240;
 
scale_w_total = scale_w * 320;
scale_h_total = scale_h * 240;

screen_position.x = (info->current_w - scale_w_total)/2;
screen_position.y = (info->current_h - scale_h_total)/2;

real_screen = SDL_SetVideoMode(info->current_w, info->current_h, info->vfmt->BitsPerPixel, SDL_HWSURFACE | SDL_NOFRAME);
screen = SDL_CreateRGBSurface(SDL_HWSURFACE, 320, 240, info->vfmt->BitsPerPixel, 0,0,0,0);
#else
screen = SDL_SetVideoMode(320, 240, 16, SDL_HWSURFACE);
#endif


Then for drawing everything on-screen :

#ifdef SCALING
SDL_Surface* doble;
doble = zoomSurface(screen,scale_w,scale_h,0);
SDL_BlitSurface(doble,NULL,real_screen,&screen_position);
SDL_Flip(real_screen);
SDL_FreeSurface(doble);
#else
SDL_Flip(screen);
#endif


EDIT: My solution here works with all screens but if you like your upscale code better,
it's up to you really.

Would those routines allow him to use actual full screen modes?

Quote from: DJ Omnimaga on September 16, 2015, 01:11:28 AM
Would those routines allow him to use actual full screen modes?

It' works with fullscreen modes with no issues but fullscreen is evil, especially on Linux.
This code has no need for fullscreen and my code here actually runs on a window without borders,
which works better on operating systems like most linux distributions.

EDIT: Also matref, i forgot to tell you that but you need to get the bpp using SDL_GetVideoInfo
and you need to use the detected bpp for your RGB Surface and screen surface or else SDL will have to do some conversion,
wasting a lot of cpu cycles.

I guess it's fine if it's simulated full screen, as in the game just stretched to fit everything on screen without changing the resolution. However, it has to be optimized a lot because in the past I saw 2D games or emulators lag like mad when the window was stretched up to high resolutions.

Quote from: gameblabla on September 16, 2015, 01:19:46 AM
It's works with fullscreen modes with no problems but fullscreen is evil, especially on Linux.

Wait what ? On Linux, full screen = borderless extended to the whole screen. It's just a flag that tells the window manager to do that. There's nothing wrong with this, if it doesn't work for you then your window manager is broken. You smoked too much Windows man. :P

Actually on Windows it's not that bad either unless you use Visual Basic 6.0 or downloaded stuff from Limewire at least once.

Alright, level 2 is now able to progress pretty fast (weird sentence huh). I'm done writing the props engine (which is actually embedded in the enemies engine) and the camera paths handling, which I'm pretty proud of. Nearly everything in nKaruga works with callbacks, making everything pretty modular.

Anyway, now that that's out of the way, I should be able to work fast on level 2. It's actually pretty good already !

(http://www.mirari.fr/IlbJ)

As always, if you want to help with sprites, I need that, so please tell me. Thanks in advance !

OMG that looks even more matrefaywesome O.O. This program is in the news pending queue but I didn't have time to write it yet and I lost the download link. >.<

I wonder if a flying Walrii easter egg would be cool? :P (eg if the player types w a l r i i letters in-game, it would do like when you type /walrii in WalrusIRC)

Bump !

nKaruga v0.2.0 is out ! It features the full second level, up to the boss battle, which isn't implemented yet : http://gamejolt.com/games/nkaruga-2d-ikaruga-demake/92026

Also, great news : 100% of the final game's mechanics have been implemented ! That means that all of what is left to do will be relevant to AI writing, level design and graphics. Isn't that nice ?

But that means I need help more than ever ! If you want to help me with sprites, make sure to let me know.

DJ : easter eggs will be relevant when the game is done. Until then, I'll just focus on the important parts.

Awesome! I didn't see this until now because I was kinda sick. I'll try the new version soon. Glad to hear that the game mechanics  were completed by the way. :)

Sprite requests should go in the drawing and animation board, though.

Sounds fun. Good luck finishing it. I can't really help you with the sprites though. :P

On a side note @matrefeytontias , I'm still a bit sad that on the Gamejolt file description page, there is not even a single mention about how the game is a port from the TI-Nspire calculator nor any link to the original. There isn't even the word "calculator" nor "TI-Nspire" there (I did CTRL+F to search). D: It would give calculators more publicity outside the community and not make them look irrelevant in the history of this project. :P

I plan to do that when I'm done cleaning up the description. It's already too much of a mess :P

Ok good to hear. :) I was a bit worried that calculators were thrown out of the window there. :P

Is this project open source or could you send me the source, I'd like to port it to the GBA (with your permission of course)

It probably depends how much resource-intensive the Nspire version was. If the Nspire CX CPU was maxed out at 232 MHz during gameplay then the 16.78 MHz GBA will probably have a very hard time running it. But you could simply rewrite parts of the game from scratch instead of doing a straight port. Doesn't the GBA have some mappers and stuff to make it easier to make 2D tilemap games with parallax backgrounds?

Quote from: DJ Omnimaga on October 31, 2015, 03:16:10 AM
It probably depends how much resource-intensive the Nspire version was. If the Nspire CX CPU was maxed out at 232 MHz during gameplay then the 16.78 MHz GBA will probably have a very hard time running it. But you could simply rewrite parts of the game from scratch instead of doing a straight port. Doesn't the GBA have some mappers and stuff to make it easier to make 2D tilemap games with parallax backgrounds?

Yes, the GBA has hardware accelerated backgrounds and sprites and stuff, so that should greatly help with speed. I've seen much more advanced games running on the GBA, so it should probably be able to handle it.

Yeah, hardware acceleration would be your best bet. I was more worried about how much of the game would need to be rewritten, especially if neither nSDL nor n2DLib are available for the GBA.

Bump !

I've been awfully busy with school these days, as exams (contests really) are coming up in a couple of months. It's stressing the s*** out of me, so I'm taking some time to relax and work on nKaruga.

And I'm glad to say it's paying off, as I now have a new and independent system menu - with menu sounds in it ! Also, the biggest announcement is that level 1 now has original music ! My friend blvtch (on Youtube and Steam, RGBMusic on Facebook, check him out he does chiptune) is working on the music for the game, which will consist in chiptune rewrites of musics from the original game. Isn't that great ?

Anyhow, you can test the private build here : http://www.mirari.fr/4c9Q

Share your thoughts by the way, and the request for sprites still holds.

EDIT : woops, looks like I forgot to include the audio. One day I'll figure out how to embed them directly in the game so that I have a standalone executable. Fixed, same link.

Darn, I hope your school schedule gets less hectic next semester. >.< I would hate never having free time.

Also I didn't have time to try this new version yet but I'm glad there is now sound. I'll try it soon :)

EDIT: Ok I tried it and I like the result. I think some levels should have faster music like in Touhou or some of the Japanese stuff, though :)

Interesting. Make a CE port and LG. :P
Please?

I think matref quit calc stuff and moved to PC programming. SOmeone else would have to do it. I wonder how hard it would be to port the game, though, considering the CE speed and RAM is much inferior to the Nspire...

I just think the TI-84+'s IkarugaX should be ported to the CE.

Oh ok, I thought you meant the TI-Nspire CX version. Matref had issues getting the CX version to run at a fast enough speed, so a CE version would need to be closer in style to IkarugaX than nKaruga. The 84+CE is reportedly 48 MHz, while the Nspire CX can run over 220 MHz.

Anyway back on topic, I can't wait for the next nKaruga PC update. :) I think it should have some 8-bit music tracks in the style of this :P

https://www.youtube.com/watch?v=aFeL7kTw2CU

Quote from: Dudeman313 on February 04, 2016, 01:39:23 PM
I just think the TI-84+'s IkarugaX should be ported to the CE.

Another port that would be facilitated if Axe was ported to CE. Actually all game ports would be.

That's why we want Axe for CE, not to have a bridge language between Basic and Asm, but to port everything faster and have an on-calc language.

nKaruga has no trouble running at full-speed on TI-Nspire CX, even non-CX. It's just that I thought that the game deserved a bigger audience than only the TI-Nspire scene - eventually I want to become a professional game dev so that's definitely a good thing to add to my portfolio.

You can still disassemble IkarugaX (good luck with that) and use MateoConLechuga's black-white to color helper tool thing. I don't remember how it's called but I know it exists.

DJ, regarding the music Blvtch is actually making remakes of the original game's music, so there's not much to do about it I guess.

Has anyone ever noticed that when playing IkarugaX, that when there are bullets on the screen, the game sloooows down a lot?

Oh really --' remember the game runs at 6 MHz, not 15. Of course it's slow, with this much activity on that poor TI-83+ screen (originally).

Oh. But would it still run fast overall if it was ported to the CE with the Nspire's graphics?

Well that's not really possible since nKaruga (the Nspire game) is a different game from IkarugaX (the 83+ game). One is not a remake of the other.

Though I suspect it could run pretty well if you stripped the background.

Quote from: matrefeytontias on February 12, 2016, 01:13:12 PM
Well that's not really possible since nKaruga (the Nspire game) is a different game from IkarugaX (the 83+ game). One is not a remake of the other.

I was unaware of that... :P
I just think I'd like having IkarugaX on my CE, but with graphics as cool as nKaruga.
EDIT:
Well, now I'm confused...

Quote from: matrefeytontias
This is the beta release of nKaruga, a faithful clone of the famous shoot-them-up Ikaruga for your TI-Nspire !

Are you sure it's not a remake? 'Cause I thought that's what a clone was...Unless you ment it just had different and better features, which in that case, I would want to have an nKaruga port on my CE possibly called cKaruga. :P

IkarugaX and nKaruga are both clones of the same game, Ikaruga, but those two are not related.

Well, in that case, there should be a IkarugaCE.  ;)

Quote from: aeTIos on February 12, 2016, 01:27:08 PM
Though I suspect it could run pretty well if you stripped the background.

You would also need to lower the color depth. On the 84+CE there are multiple display modes it seems (even a 1 bit color mode, according to the Alien Breed topic), which basically use a smaller portion of the screen, but displayed in 320x240 resolution with fewer colors. This would increase the game display speed.

Nah, I'm pretty sure you can keep it 16-bit. Maybe make it 8 bit for retro effect (double sized pixels gogo)

The pixels would not be double-sized. When you switch to 8-bit mode on the CE while in TI-OS mode, the screen basically zooms in like this, with different colors:

(http://img.codewalr.us/ce8bits.jpg)
https://youtube.com/watch?v=zFVD8od6qdk

Then you can use each individual pixel in the 320x240 grid, but with only 256 colors.

I don't see why you'd need more than 256 anyway.

Bump !

I finally, finally found an artist, and goddamn he's a good one. So just like that, development has resumed, and this time I'm working on the second boss ! Just look at this glory !

(http://www.mirari.fr/3Sqf)

I'm having a hard time understanding what my code does. It's been nearly a year since I last worked on a boss ... bosses have an engine of their own, with complex math to handle jointed images and all that, so it's really hard to get back into it after so long. I have faith though !

Awesome to see you found an artist. :D Nowadays, pixel artists seems very hard to come by on forums, so much that for calculator games, authors have to program with the mindset that nobody will ever help them making graphics. So I'm happy you were lucky enough to found one.

Anyway this looks very cool in-game and I'm glad the game is still progressing. For some reasons, though, it still seems to have the cropped digit fonts bug, though. Is that really a bug or was it intentional?

Well the way the font looks is intentional. Basically I have a monochrome font, and I procedurally generate an outline with the color passed as an argument. It's the isOutlinePixel function in n2DLib (you can read it on GitHub) ; I made it look that way intentionally.

Aah ok. It seemed like the outline was cut off, hence why I was asking. I see now, though.

Bumpity bump !

A very late update on this. I successfully finished my competitive exams, which took 4 months, from the start of April up to the end of July, so development has been slow or non-existent during that time. But now, I have a lot of progress going on, as you can see on the playable 0.2.3 build on GameJolt (http://gamejolt.com/games/nkaruga/92026) !

To sum it up :

• Boss 2 is complete ! That means level 1 and 2 and boss 1 and 2 are fully playable, meaning that the full game is technically about 40% playable ! Although it's much more finished than that, since approximately 100% of the core mechanics are written, tested and working, and all that's left is art, level design and AI programming for the future enemies.
  
• I moved from Visual C++ to GCC/g++, meaning ... portabilityyyyy ! The source code is platform independent and should compile effortlessly on any platform. Not tested, but heh, you know :P Also, a lot of dependencies issues should have been fixed by that, so the current Windows executable should run flawlessly on every recent-enough Windows version (up to and including XP I think).
  
• I found a new artist after the last one stopped answering (due to 4 months of inactivity on my part, granted) ; he drew the two backgrounds for level 2, and I'm currently adding them to the game with the newly-written background scrolling system (which supports normal and parallax scrolling as well as scaling).
  
• A much-demanded request, you can now use either WASD/ZQSD or the arrow keys to control your ship. The rest of the controls is still configurable.
  
  Try out the game and tell me what you think, as always !

Awesome! I was wondering if it had any progress actually. I'll definitively give this a try because the last time I only reached Boss 1. It was very-well polished and I'm sure this version is even more.

I wonder if such game would be feasible in web format or if it would be way too slow? That would definitively be a nice addition to the CodeWalrus arcade section once finished. On a side note, backup often, including binaries, because of what happened to Yoyogames Sandbox. Given that such big sites tend to disappear after a while, we never know if Gamejolt is next.

Portability is a good thing :)
Depending on the graphics layer you're using, it may even be coerced to run from within a modern Web browser, as asm.js + WebGL for now, or WebAssembly + WebGL in the relatively near future.

Hey @Lionel Debroux nice to see you again. I was worried that you had quit the TI community or something. As for a web port, my main concern is how slow it will run. Just look at how laggy Opossum Massage Simulator can get in the arcade section compared to its PC counterpart O.O (in my case it runs smoothly, but it maxes out my CPU)

So I played through the first chapter again and the start of chapter 2 and I was curious about how we get past this part without getting hit once? O.O

(https://img.ourl.ca/nkarugachapter2.png)

Also a bug I noticed is that when the game window is in the background (as in, when I decide for example to use Firefox while the game is paused and I'm not focusing on its window), my computer CPU and fan get maxed out. When the game is running and I'm focusing on its window everything is fine.

@matrefeytontias
Could you please release your source code for your PC version, even if not finished ?
Or hell, put it on github.

I would like to port this game to the GCW0 but the only source code online is the old nspire version.
Or hell, even port it back to the TI-Nspire and the 3DS thanks to my wrapper library (https://codewalr.us/index.php?topic=1658.msg46785;topicseen#new).

Hey,

I've been actually currently working hard to get this game to work on Linux. Now that it's done (I was done with that yesterday), I'll be able to release the source code. I've had a private GitHub repo for nKaruga for a week or so, so it's here now. Feel free to grab it : https://github.com/matrefeytontias/nKaruga

Also hey, kinda forgot to push the updates here. So nKaruga is now on version 0.2.5 ! I included new parallax background for all released levels, I programmed a super beautiful awesome (and c) transition for level 2 (check it out ! (https://twitter.com/nKaruga_dev/status/784183626787414016))I finally made the necessary changes to my code to load OGG music files and drop WAVs, dropping the package size from 48 MB to 9 MB. I also released the listenable OST on the GameJolt page.

Version 0.2.6 should be the last version before 0.3.0, and will include a time-frames implementation. That is, frames will have a timestamp to them, so that time-dependent things like events related to the music will always be accurate regardless of the framerate. After that, 0.3.0 will be the first release to include (at least a part of) level 3. The artist I'm working with right now seems to be sticking around, which is good :P

So yeah, to sum it up, I'm working on making Linux builds right now. If anybody can build a Linux 64-bits version for me using that repo I just posted and send me the resulting release, that'd be appreciated. Next, I'll implement time-frames and then release 0.2.6, and then on to level 3.

Regarding your ports Gameblabla, feel free to fork the repo and include any other target you wish. My Makefile already offers make windows and make linux targets, so why not make nspire.

Wow that transition is amazing O.O. Also will Windows still be suppirted in future update? :P

Thanks matref !
I see you have a problem with scaling.
Simply replace this :
SDL_CreateWindowAndRenderer(320 * 2, 240 * 2, SDL_WINDOW_BORDERLESS, &sdlWindow, &sdlRenderer);
with this :
SDL_CreateWindowAndRenderer(320 * 2, 240 * 2, SDL_WINDOW_FULLSCREEN_DESKTOP, &sdlWindow, &sdlRenderer);
And SDL2 cleanly fills up the screen.

Now please drop your internal resolution to 320x240.
I'm asking you because it seems you hardcoded it rather than making it parametrable and i couldn't get 320x240 to work without it crashing on exit.

Also, i see you're still stuck with software rendering, even though it's far from optimal.
Dropping the resolution and removing your internal scaling will speed it up a bit but using textures might be better.
I will look at this, in the meantime, fix the scaling issue please.

@DJ : Thanks, I'm quite proud of it yeah :P

No, I'm dropping the Windows target, and then I'm gonna port it to 3DS and then drop the Linux target :D

@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.

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.

Quote from: matrefeytontias on October 28, 2016, 12:25:35 AM
@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

QuoteI'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.

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.

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

Well you're gonna fork it anyway, so feel free to do whatever you want with it :P 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.

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.

Quote from: matrefeytontias on October 28, 2016, 01:11:19 AM
Well you're gonna fork it anyway, so feel free to do whatever you want with it :P 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 (https://gameblabla.nl/img/nkaruga_fullscreen.png)
And how it looks like with aspect ratio correction :
https://gameblabla.nl/img/nkaruga_fixedratio.png (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-xenial-amd64.deb)
https://gameblabla.nl/files/nkaruga/nKaruga-windows-x86.zip (https://gameblabla.nl/files/nkaruga/nKaruga-windows-x86.zip)

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

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

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 ?

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

QuoteFor 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.

Quote from: matrefeytontias on October 28, 2016, 01:30:59 PMChanging 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)

QuoteAlso, 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 ?)

QuoteI 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

QuoteSame 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.

Quoteexcept 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 (https://github.com/gameblabla/nKaruga/commit/cd75fb479adcf169ef33d9bd587b84c8059a2d02)

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

Quote from: gameblabla on October 28, 2016, 03:19:00 PM
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.

Quote from: gameblabla on October 28, 2016, 03:19:00 PM

QuoteFor 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.

Quote from: gameblabla on October 28, 2016, 03:19:00 PM

Quote from: matrefeytontias on October 28, 2016, 01:30:59 PMChanging 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.

Quote from: gameblabla on October 28, 2016, 03:19:00 PM

QuoteAlso, 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.

Quote from: gameblabla on October 28, 2016, 03:19:00 PM

QuoteI 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.

Quote from: gameblabla on October 28, 2016, 03:19:00 PM

QuoteSame 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).

Quote from: gameblabla on October 28, 2016, 03:19:00 PM

Quoteexcept 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 (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.

Quote from: gameblabla on October 28, 2016, 03:19:00 PM
i think i miss but you ate me matref.
You ate me.

... what ?

Quote from: matrefeytontias on October 28, 2016, 03:41:03 PM
, 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 <_<

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.

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

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.

QuoteWell 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.

QuoteThat'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 ?

QuoteI 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.

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

It makes all sense now !

QuoteWell 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.

QuoteAlright, 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 (https://gameblabla.nl/img/nkaruga_fixedratio.png)

QuoteEDIT : 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 :

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.

Quote from: gameblabla on October 28, 2016, 04:48:23 PM

QuoteThat'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.

Quote from: gameblabla on October 28, 2016, 04:48:23 PM

QuoteWell 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.

Quote from: gameblabla on October 28, 2016, 04:48:23 PM

QuoteAlright, 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 (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.

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.


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();
}


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 :
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.

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.

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.

Quotesrc/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.

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

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.

Yeah, it works if I cherrypick this commit (https://github.com/gameblabla/nKaruga/commit/6f992c0b6a39bdb64a641db10ca65059e8303447). Anyway, look at my fork (https://github.com/juju2143/nKaruga), 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.

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.

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

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.

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...

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

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](https://gameblabla.nl/img/nkaruga_scr1.png)[/spoiler]
And here is matref's version using the software renderer :
[spoiler](https://gameblabla.nl/img/nkaruga-matref.png)[/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-xenial-amd64.deb)
https://gameblabla.nl/files/nkaruga/nKaruga-windows-x86.zip (https://gameblabla.nl/files/nkaruga/nKaruga-windows-x86.zip)

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.

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

Quote from: matrefeytontias on November 02, 2016, 05:50:38 PM
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 (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.

Well I mean if you're not gonna make a pull request you're just gonna have your fork sitting there and you'll need to keep it up-to-date with my version. Although I wouldn't advise you to do an actual pull request because it doesn't meet my requirements for the game, that is, to be able to work on it and play it without sudo rights.

Congrats on the GCW0 port though, that looks cool. Just like Juju added the Mac target, it would be nice if you could add a target for that without rewriting all of my toolchain :P

Awesome to see the game running on the GCW0 :)

Quote from: gameblabla on November 02, 2016, 06:43:47 AM

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

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](https://gameblabla.nl/img/nkaruga_scr1.png)[/spoiler]
And here is matref's version using the software renderer :
[spoiler](https://gameblabla.nl/img/nkaruga-matref.png)[/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-xenial-amd64.deb)
https://gameblabla.nl/files/nkaruga/nKaruga-windows-x86.zip (https://gameblabla.nl/files/nkaruga/nKaruga-windows-x86.zip)

My PC is from 2008...  <_<
But I have a Pentium Dual Core, and my graphics are permanently Open GL 1.1.
I'll try it from Linux.

Quote from: Jkolade936 on November 04, 2016, 12:31:32 AM
My PC is from 2008...  <_<
But I have a Pentium Dual Core, and my graphics are permanently Open GL 1.1.
I'll try it from Linux.

Feel free to give the Linux version a try.
However, SDL2 only requires Direct3D 9/OpenGL 1.x for hardware rendering so it should work on your PC as well.

Worked great! Game was smooth and speedy. Icon's cool, but when the WARNING message comes up, the background just scrolls and there's no more action.

Quote from: Jkolade936 on November 04, 2016, 01:41:44 AM
Worked great! Game was smooth and speedy. Icon's cool, but when the WARNING message comes up, the background just scrolls and there's no more action.

Hmm... I think i had pushed a buggy build.
I'll fix that, thanks JKolade. (surprised you made it this far !)

I mean you get infinite continues, so you can finish the game no problem :P you'll get 0 points though, obviously, because your score and max chains are resetted on every continue.

@Jkolade936 can you test my build ? I don't have a Linux machine available unfortunately so you'll have to compile it yourself. It should be easy though, just download the source code (https://github.com/matrefeytontias/nKaruga) as a zip ("Clone or Download" button), extract it somewhere and run make linux in its directory from a terminal. You can then run bin/nix/nKaruga.

EDIT : if you guys want a challenge, try to beat my highscore of over 4 million points after level 2. I did that by getting every single possible score chain from the first level and most of them in the second one (while not doing in the process, except maybe against the second boss).

Quote from: gameblabla on November 04, 2016, 01:43:55 AM

Quote from: Jkolade936 on November 04, 2016, 01:41:44 AM
Worked great! Game was smooth and speedy. Icon's cool, but when the WARNING message comes up, the background just scrolls and there's no more action.

Hmm... I think i had pushed a buggy build.
I'll fix that, thanks JKolade. (surprised you made it this far !)

It was fun! I used [Z] for polarity switch, [X] for fire, [C] for power release and [Enter] for continue after dying several times. :P

Quote from: matrefeytontias on November 04, 2016, 02:01:15 AM
I mean you get infinite continues, so you can finish the game no problem :P you'll get 0 points though, obviously, because your score and max chains are resetted on every continue.

@Jkolade936 can you test my build ? I don't have a Linux machine available unfortunately so you'll have to compile it yourself. It should be easy though, just download the source code (https://github.com/matrefeytontias/nKaruga) as a zip ("Clone or Download" button), extract it somewhere and run make linux in its directory from a terminal. You can then run bin/nix/nKaruga.

EDIT : if you guys want a challenge, try to beat my highscore of over 4 million points after level 2. I did that by getting every single possible score chain from the first level and most of them in the second one (while not doing in the process, except maybe against the second boss).

Sure, after I figure out how to fix elementaryOS. I accidentally managed to delete my entire home directory, and I can't put the backup there because of an annoying "Permission Denied" message. I'll make a new topic.

Yeah those are the most commonly used danmaku coontrols. I kinda liked my left-handed I,O,P though :P glad you like my game anyway.

And wow the home directory thing sounds bad. Good luck with that, although if all you're getting is a permission denied, you should try sudo-ing it up.

I don't know how to get heightened privileges in the file explorer, and now I can't even log in.
I really don't want to lose my files tho.

Gosh, I hate double posting. >.<

Anyhoo, I completely scrapped my files and reinstalled, then tried to compile the build. I got this:

Building src/ExplosionAnim.cpp to bin/win/obj/ExplosionAnim.o ...
g++ -c src/ExplosionAnim.cpp -I./SDL2/nix/include/SDL2/x86_64 -I./SDL2_mixer/nix/include/SDL2/x86_64 -o bin/win/obj/ExplosionAnim.o -Wl,-rpath,'$ORIGIN/lib' -fpermissive -Wno-write-strings -Wno-pointer-arith -Wno-overflow -std=c++11
Assembler messages:
Fatal error: can't create bin/win/obj/ExplosionAnim.o: No such file or directory
Makefile:56: recipe for target 'bin/win/obj/ExplosionAnim.o' failed
make: *** [bin/win/obj/ExplosionAnim.o] Error 1


You're working on Linux right ? Then you should run make linux, not make, that's for Windows.

I did, @matrefeytontias . I did. ???

Well that's weird. It seems to be fetching the correct SDL2 lib files (see the /nix/ part) but writing in the wrong obj directories (see the /win/ part). What version of Linux are you using ? Also, can you quote me the first few lines (10 or so) of running man make ?

Quote from: matrefeytontias on November 04, 2016, 02:01:15 AM
I mean you get infinite continues, so you can finish the game no problem :P you'll get 0 points though, obviously, because your score and max chains are resetted on every continue.

@Jkolade936 can you test my build ? I don't have a Linux machine available unfortunately so you'll have to compile it yourself. It should be easy though, just download the source code (https://github.com/matrefeytontias/nKaruga) as a zip ("Clone or Download" button), extract it somewhere and run make linux in its directory from a terminal. You can then run bin/nix/nKaruga.

EDIT : if you guys want a challenge, try to beat my highscore of over 4 million points after level 2. I did that by getting every single possible score chain from the first level and most of them in the second one (while not doing in the process, except maybe against the second boss).

At least I am glad it's not like Hong Kong 97, where if you take one hit, the entire game is over, or like in those hard as hell NES games that lacks checkpoints and continues. >.< The difficulty is also a bit easier than Ikaruga overall at first, although by level 2 it gets insane. Sadly, I didn't have time to get further than I was last time, though. I need to give the game another try. I also forgot my highscore.