Uzebox Forums

Artcfox wrote: ↑Sat Jul 25, 2020 4:35 pm I'll give this a shot when I have access to a Windows machine.

Any news on this one? Still waiting for results before committing this change. Of course anyone else, please give it a go, whether it has any problem with sound.

zigfreid wrote: ↑Wed Aug 19, 2020 3:53 pmHello!
I fixed "Whack-a-Mole" by myself, but now i'm getting linker error in the "Zombienator":

This after applying the fix I mentioned earlier? Could you please check that and report how the games are affected? (Still waiting for it before committing)

It appears that both the game and the kernel are defining global variables with the same name, which is undefined behavior. Without looking closely, I'm not sure if the intent of the game code was to declare those variables as extern and to have the game modify the variables defined in the kernel, ...

Now, when you start using programmatic techniques to flash various parts of memory you really need to be careful of bugs. An RPG might have some amazing graphics by using a separate rom for every screen and doing a flash each time the character moves to another screen. That would not be a realistic...

We did attempt some designs where the Bootloader could be asked to flash further parts of the game to allow for more than 60K as a multi-part game, however it is not encouraged: there are only about 10000 writes the AVRs internal flash can endure. However in the current Bootloader, the feature exist...

Could you try a compile removing the following line from Video Mode 2's source? https://github.com/Uzebox/uzebox/blob/master/kernel/videoMode2/videoMode2.c#L41 I don't even know how it is supposed to work with that line there as the structure is provided by the assembly source , so there indeed shou...

Similar fix is working also for sokoban_move function. So your Could you explain please the rootcause of my problem? Many thanks. Did a bit of research as I don't use inline myself ("static" does the job, the compiler will sensibly inline it wherever possible). What seems to be the case i...

Could you test this with your distro's packaged avr-gcc? This is a pretty new version of gcc, guessing you might have installed it yourself. I checked the code which gives you the error, I see nothing odd in it, the referenced functions exist in it, sokoban_move() certainly without any dubious const...

I actually think that you ended up doing it with just 2 colors + transparent black. I'm pretty sure you can add 1 more color to each line for a dithering effect, but CunningFellow would know for sure. Thanks :) There are quite more than those three which use 3 colours, for example notably the botto...

Did an attempt at it!
Also attached palette in case you had difficulties properly porting it. Hope it fits! (All the three zeros use the same set of tiles, there are some opportunities to trim tile count beyond that, quite some tiles are the same)