Join us on Discord!
You can help CodeWalrus stay online by donating here.
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - matrefeytontias

#16
You're working on Linux right ? Then you should run make linux, not make, that's for Windows.
#17
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.
#18
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 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).
#19
Quote from: DJ Omnimaga on October 27, 2016, 07:05:22 PM
Also that idea reminds me of how persalteas managed to release an Axe game for the TI-82 Stats/83. Axe is not available for the TI-82 Stats/83, so basically he grabbed the hexadecimal after disassembling the game then modified what's necessary to become compatible with the older calculator, then he was set.
Hum ... that was me :P and that was Jetpack 8x+ too.

@E37 you might want to take a look at my PageSwap axiom. It should be somewhere on Omnimaga.
#20
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
#21
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.
#22
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.
#23
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.
#24
Yeah, GCC allows that with -fpermissive, and I find it useful and practical so I use it. Thanks for trying.
#25
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.
#26
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();
}
#27
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
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.
#28
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.
#29
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.
#30
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
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 ?
Powered by EzPortal