You're working on Linux right ? Then you should run make linux, not make, that's for Windows.
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 MenuQuote from: DJ Omnimaga on October 27, 2016, 07:05:22 PMHum ... that was me and that was Jetpack 8x+ too.
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.
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();
}
Quote from: gameblabla on October 28, 2016, 04:48:23 PMI'd rather just have the people configure their own keys as they want. It's just selecting a menu option and pushing 4 keys.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 ?
Quote from: gameblabla on October 28, 2016, 04:48:23 PMNope, 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.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.
Quote from: gameblabla on October 28, 2016, 04:48:23 PMWeird, 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.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
Quote from: gameblabla on October 28, 2016, 03:19:00 PMSo funny and relevant to the discussion. Thanks for helping nKaruga grow into a good game by the way.
lol matref, so much anger. I did not even need to troll you, just to fork your repo and remove all you did lol.
Quote from: gameblabla on October 28, 2016, 03:19:00 PMAgain, 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.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 didYeah; 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: gameblabla on October 28, 2016, 03:19:00 PMThat'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: 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)
Quote from: gameblabla on October 28, 2016, 03:19:00 PMWell no, you should have gperf'd it before that commit saying you made it faster.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 ?)
Quote from: gameblabla on October 28, 2016, 03:19:00 PMI 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.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
Quote from: gameblabla on October 28, 2016, 03:19:00 PMI work on Windows 8.1, KDE 64-bits (school machines) and Ubuntu 32-bits (in a VM).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.
Quote from: gameblabla on October 28, 2016, 03:19:00 PMWell 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.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
Quote from: gameblabla on October 28, 2016, 03:19:00 PM... what ?
i think i miss but you ate me matref.
You ate me.
Page created in 0.076 seconds with 30 queries.