Actually, the latest releases are in the "Releases" section. Thanks for your willingness to help, though.

Oooooh I see now. I'm not entirely sure why Pre-releases don't show up on the landing page for repositories, but they don't.

So I guess this could be classified under "noob misunderstandings"

I've never noticed that, lemme fix it:

Comically large release link
I didn't mark the latest release as a prerelease so it's easier to see from the main page; they should show up regardless of tagging, but somebody at GitHub had to mess up I guess (let's just say it's Microsoft's fault to appease the Linux users). Anyway, delete your old save or quit your current game, just don't have an active run or the calc crashes blah blah blah same as per usual. I do have excellent news for you all though, I got rid of some of the background tiles and managed to free up a fair amount of heap usage, so weird bugs are now unlikely and you should only have to deal with regular bugs, which are also weird but not as catastrophic! I'm using some of the new space to decompress more sprites, and I'm trying to figure out how to best take advantage of it without completely rewriting the game from scratch around weird techniques. I might be able to really shrink the game down, or at least keep it from getting bigger as I add more sprites.

Thank TIny for the TItle:


For anyone who's curious, the old game size was 206,317 bytes, the current size is 191,936 bytes. It's still insanely large, but I can definitely shave off more after I clean up the decompression code. Here's what's changed so far:

-Code organization
-Code obfuscation
-New way to draw menu sprites, should allow for compressing more sprites in the future
-Opening screen looks less empty
-Official title added
-More unnecessary comments and puns
-Fixed visual glitch during the death animation
-Removed random pink line from laser powering down animation
-Added gramophone and lamp (sign coming soon)

I wouldn't be surprised if there're new graphical bugs with the background sprites since a lot has changed under the hood. Tell me if there's bugs, make fun of how bad the code is, complain about the file size, and have fun!

Oh, and I made a release on GitHub earlier that didn't have most of the optimizations and bugfixes in it. It worked, but I'd redownload it if you got it earlier.

This looks great! I'm excited to see more and more of the game come together, and I'm really loving the progress so far. Awesome job making the program take less, and the start screen looks a lot better with the gramophone and light. Keep up the great work!

I accidently broke my promise from last Capitalist's Day's Eve. I think it's clear what must be done. Merry Capitalist day!

The project appears to be progressing well, I look forward to seeing more development.

Heller peeps, version 0.20 is out and I highly recommend it since it fixes a really weird bug where resuming the game would sometimes kick you out and then lock you out entirely. As far as I can tell, the variable for holding how long Barry's corpse has been on the floor would randomly set to above 50 (the number of frames, which is about 2 seconds), making the game think you'd died and it was time to end the game, but since the health wouldn't be zero, it's treated as exiting out of the game. Entering it from the OS would run through all the checks fine but the game wouldn't even run and would immediately exit. I don't know how it happens and I can only assume something's writing to the wrong pointer and only to that pointer with some random value that's sometimes above 50. I've changed the exit code to also check for zero health and put in some data fixers to make sure it starts and ends with the right value.

Oh, and I was working on other things before I found this and held off posting for some reason:


Because of the unfinished bits under the hood that'll be finished next update, I've had to change how the save data structure works so that some data is moved around for ease of access. Finish or quit any running games and then send the updated program. If there are any bugs (and I'm sure there's more) then please tell me.

This looks freaking awesome. The code still makes me cry a bit though.

I'm not sure how I feel about delay being used to slow down the code, I would recommend a timer that triggers updates instead.
You can also optimize it by keeping your drawing separate from your other logic, increasing FPS.

Do you think you can update the makefile with the latest template one from the toolchain?

EDIT: wtf, why are you using timer 2 to count things when timer 2 is being used by delay()!?!? Come on man. delay() RESETS timer 2 and thus all of your "FPS" measurements are completely wrong.

Awesome work on this! The animations and transitions are looking smoother than ever, and I particularly like the new partial transparency effect you did on the pause menu with that checkerboard mask. Performance is great as well, 40+ FPS is more than acceptable considering all of the different sprites and fancy graphics.

The one thing that is irritating me is that white flash when starting the game before Barry appears. Is there any way to fix that? It seems like you maybe could with some kind of screen swapping/blitting.

The white flash is in place instead of a break-in animation currently, not a graphical bug IIRC.

I honestly don't know, at some point I recall I couldn't use timer zero without any use of delay() instantly freezing the calc, and then later when a bugfix came out I couldn't use timer 1. I'll change it and tell you what happens, and if I wrap my head around timer interrupts I'll use those, that's been on the "change if someone complains since it works fine" list for a while now.

And ditto to what TIny said, the flash is a part of the explosion animation and I suppose it needs to be little bit greyer so it doesn't look so out of place with all the darker colors.

UPDATE: Yeah I have to use timer 2, timer 1 still freezes and timer 3 obviously doesn't work whatsoever. Also, my makefile is "identical" to the existing one on the toolchain as far as I can tell, aside from my extra flags of course. Here's the latest toolchain makefile versus my current makefile.

Pretty sure your code is just wrong then - the only way it is working now is because delay() configures the timer properly for you out of coincidence. And timer 0 doesn't even exist so?! I guess just don't expect anything to work if a new toolchain comes out.


I don't know what you are smoking, but those certainly are not at all identical. Literally look at the lines below the dashes. Remove the CEDEV nonsense.

my joyride isnt working thru cesium, it says i need libloader, but i already have it...

Are you sure you have the latest version of the C libraries, which you can get here?

Also, keep in mind that Jetpack Joyride hasn't been officially released yet, so it's possible that this could cause some issues for your calculator. KingDubDub would know a lot more than I do about the safety of running it on hardware--maybe he could elaborate on some of the risks?

That is exactly what has happened, any call of delay with any values while using timer_1 freezes the calc. I meant to say timers 1 and 2 but used 0 and 1 because I've been calling too many arrays lately, that's bad. I've removed kb_SetMode() since I know that can mess with interrupts but nothing changed. If delay() is configuring timer_2 correctly, then what should I do to make sure timer_1 starts correctly?


Of course they aren't identical, everyone and their dog can see that. They are quote identical endquote. I'll remove the extra lines if it bugs you so much, but I don't see any benefit from removing an extra warning.

EDIT: I'm sorry mntstew, I had written this post last night posted this this morning during my first classes assuming no one had posted since Mateo. I'm building this with the latest toolchain libs, so make sure you have those updated as Epsilon said. The program is supposed to be safe, and I've been trying to be careful with savedata functions so I don't overwrite people's OS's or something. All in all, there's no risk that I can think of since I've only used janky pointer math in a few places with limits in place. In case it still doesn't work, here's LibLoad from my CE and I'd suggest using asmhook because it's easier and since I'm really dumb and keep using too much RAM. I've been working on it but you may have trouble using shells to run JPJR as you run out of RAM. Please don't multipost about one thing either, all questions/bugs/whatever can go here where I'll be able to find them easily. Tell me if it works, and have fun if it does!

Because the toolchain doesn't use that variable anymore. So anyone who downloads the toolchain and tries to build your project will be unable to.

You fell victim to the same backwards incompatibility that Oiram did as a result of https://github.com/CE-Programming/toolchain/pull/325. Sorry about that.

The simple fix is to use timer_Enable() and timer_Disable() instead of manipulating timer_Control directly. Here's the fix I made to Oiram, for reference: https://github.com/mateoconlechuga/oiram/pull/18/commits/70d4319c28e012e09e9a1907b78e7dd8211edfaa

A better fix is to refactor your code to make use of the clock() function, introduced by the PR that introduced this issue.

is the a button where i can download it because i'm having trouble finding out how to get the file with the game