This looks awesome. The code could use some work, but who cares... Keep up the good work!

I tried out the demo and it was pretty awesome! I did run into a strange bug where it would randomly (typically on the first restart) start stuttering so bad, it would get about 1fps and the screen would flicker pink or yellow. Sometimes it would fix itself after a random amount of time which was weird. If I quit and re-entered the game while it was stuttering, it would keep doing it unless I deleted the JTPKDAT file. This leads me to believe there's something getting messed up in the appvar so I've uploaded it here for you to check out: [link removed]

Besides that, the game looks and runs fantastic. Well done!

I tried it out as well and it stutters like TheLastMillenial said, but it didn't reset my ram and it went away after a while. it was kind of like the version right before this one, except that when it is glitching it doesn't go quite so slow, and there are random dots on the screen instead of a solid yellow rectangle. I also deleted the appvar but the problem came back after a while. it worked fine 3 versions ago (before the cool bouncing corpse animation), so I agree with TheLastMillenial that it is probably because of the new appvar formatting u said u had.

Does it occur in CEmu or only on hardware?

And thus I have shed many tears and held down ctrl-z for a good 20 seconds and watched ~50 bytes add back to the code. Anyway, I fixed the fix to fix things that didn't need fixing. I've had two people test this and say it didn't have problems, both guessed it had something to do with the missiles and it's believed to happen when the lasers and missiles are onscreen at the same time, which makes sense if the appvar data is reading/writing the missile and laser vars on top of each other and creating bad data. I had checks to fix that but they've been phased out to reduce size, I guess I'll need to look into adding those back (also when was the last version bugging out? I didn't know there were issues with the graphics at the time). Anyway, break it again and I'll fix it before moving on, I'll see about adding the appvar structure back in a cleaner way and work on the game-over screen.

UPDATE 0.15.0:

I've added horizontal zappers since people actually do play this game, obviously that messes up the appvar pretty badly so you'll have to delete it or just watch the fireworks. I also fixed some issues with the jetpack bouncing but that's irrelevant. Try it if you want, please tell me what else I broke!

Oh yeah, have a picture:


UPDATE 0.16.0:

This is just a "I spent 4 hours of sleeping time doing this so Im'ma upload it" update, although I did figure out why missiles were acting weird. The appvar definitely had issues that messed with the gameplay, but the real issue was that I was saving some animation values and then treating them like they were starting at zero upon reloading the game, a frame-perfect exit from the game would cause values to go out of range, and the check system wouldn't know if it needed to be a positive or a negative value. Stuff got out of range, errors ensued, and now we're here. I also made the super-fancy backgrounds and set up a simple scrolling system (because the tilemap functions are overkill) and now the compressed size has gone up by 30kb. I was worried about that, but I think I can dither it down in the future or have lower-res graphics appvars for those who have really tight storage. Considering that people are willing to put TIboy on their calcs and use tons of flash, I don't think I need to worry about size just yet. RAM is an issue though, gotta watch that!

I can't seem to get the update to work, whenever I run it it crashes. Otherwise, it's looking great and I can't wait for the next update! Maybe with menus or power-ups? TIny_Hacker hides

I'm assuming it's getting low? lol

lol if I run this from cesium it will 50% of the time run out of ram, goes up to 75% chance if cesium starts another program that starts it.

same here. the newest high res version of this game is really cool and doesn't seem to have any bugs, but it usually resets my ram if i run a couple of other large programs first.

Dub said he was planning to scale down the backgrounds and work on more file optimizations (maybe in the next update?) The newer backgrounds were somewhat of a test in my mind, but we'll have to see what the wonderful King comes up with next... hopefully less RAM usage

Also (entirely off-topic but still) Congrats on your 100th post, randomguy!

Thank you! I just noticed that I am now a member.
Edit: Although I am still a n00b.

Okay then, sounds like I'm just halving the backgrounds then, which really "quarters" them if you think about it. I figured I'd either need to work on compression for everything and maybe even some sort of dynamic code loading, or just shrink the size. However I suppose taking the lazier (and probably better) route is superior, especially since it'll cut down on the archive. I've been cleaning up the code lately and messing around with more test ideas, and I hope to have a clean(er) version of the code out soon with the shrunken backgrounds and startup zone. The biggest issue right now is deciding if I should
rewrite the entire object-rendering and collision system, since I might be able to boost the performance while making it easier to maintain.

I've also been distracted with playing Jetpack Joyride 2, which is actually real and dramatically more addictive than the original. My head hurts just thinking about porting it though, so probably not a future project (but I really do like pain, so who knows).

EDIT: I've been tinkering around and have some really good news and really bad news: the good news is that decompressing sprites is super slow but fast enough to do in the background with no obstacles or anything, the bad news is that I've hit this perfect target where I'm using enough RAM that nothing goes wrong but anything more crashes the calc instantly. Even more bad news is that gfx_ScaledSprite_NoClip() only has a noclip form and is agonizingly slow, so if I want to use it I may need to learn assembly, and that'll take as long if not longer as thinking of a better way to compress sprites. I've got a few more ideas with a last-resort one as only having one background image like before, since the detail of the sprite doesn't affect it's size in RAM (after decompression, it can increase the size before as well). Basically, more hard stuff, I need ideas, may open a toolchain request if I remember to, hopefully not taking a massive hiatus to slog through ASM training.

This is also off topic, but King Dub Dub pls make one more post you have 99 posts!!!!!!

This is my 102nd post actually, but that would've been kinda funny to become a member with a JPJR update, considering this project is my first "real" one.

Anyway, I have news; neither good nor bad but with a more optimistic outlook on RAM usage. Using some cheaty methods by abusing gfx_CopyRect() from and to the buffer, I can "dummy thiccify" a single column of pixels into a really rectangle really fast. That means the 60x250 pixel tileset for the lasers is now cut down to 60x2, and I can make it one once I diagnose either a convimg YAML error or a bug with convimg itself. I can also do the same with the pause menu buttons, where both sets have gone from 50x100 to 50x56, although the compressed program size went up by 3kb so I may have to backtrack and see if it's bloated the uncompressed code. All in all, that saves 18680 bytes of RAM space. That was awesome until I realized that I'd need 88320 bytes for decompressed backgrounds. And that's why I don't understand how to categorize this development.

I save the 690x240 nice pixel background tilesets with zx7 compression, as they take up 165600 bytes uncompressed. Checking the toolchain with absolutely no idea what I'm talking about, the total RAM appears to be around 134625 bytes. Whether or not I'm right, I can't fit the program in the RAM with all that junk. My solution is to decompress the first 8 tiles for the opening bit where Barry commits property damage and then to decompress/free the other tiles. The ninth opening tile will need to be appended when tile 0 goes offscreen completely, and the other 6 tiles are the used during most of the gameplay. I have to have at most 8 tiles out and ready, and 6 during the rest of the time. That's a difference of 22080 bytes, and so far I can only 6 malloc'd spaces by compressing all the zapper, missile, and laser sprites and commenting out their calculations. I've been staring blankly at Microsoft Paint trying to copy chunks of the backgrounds around to help unify rows for more compact images, and then smacking myself for not using GIMP's blur function like a sane person. So far, I've got the 6 tiles, but there's none of the obstacle sprites or death animations have room to be decompressed.

Here's the gibberish in my head that translates into how I'm planning for the great RAM heist:

1. Blur the background to boost compression.
2. Limit the amount of palette entries for the background since the other sprites' quality is dropping with the influx of colors.
3. THICC.
4. I can *maybe* turn the ceiling and floor into about 12 tiles each and draw them seperately, which may or may not free up another slot for backgrounds.
5. The game runs at 27-28 FPS when decompressing a single background tile every frame with just Barry on screen.
6. I have obtained 2 boxes of spearmint altoids, or 12 tins. If I consume them I will be destroyed, but for one night I will gain godlike coding skillz.
7. I need to add another compressed tile for the hole in the wall when Barry breaks in
8. I only need Barry on screen at the beginning of the game, but I'll need to add explosion sprites too.
9. Explosion sprites can just be blocks with rough gravity physics and alternating rotation so only one sprite gets changed each frame, except when I decompress something.
10. I can malloc/free RAM for the rotated death animations when the screen flashes after death, which will also add a handy delay.
11. A full code rewrite will completely change the game entropy and result in an entire engine and hopefully better code.
12. The USB bug is RAM related and can affect things other than the USB.
13. As of now, the game isn't VYSION compatible due the lack of space for code injection that leads to some spectacular graphics artifacts or "surprise crash"
14. Calculator drama is distracting.
15. I might like explaining all my logic and tricks for posterity but these posts are getting way too long.

I hope to streamline the code to a suitable point and then upload a broken version to a fork of the Github repo since Mateo wanted to check if the USB issues are due to a toolchain bug (I haven't done it yet because I didn't want to be stabbed).

As a side question that may lead to a whole new optimization rabbithole, does ti_Open() read data directly from the flash to the RAM? Is there a way I can decompress data from the flash to the RAM? Reading the compressed data into the RAM and then decompressing it takes up lots of space and I need to be as frugal as possible right now.

ti_Open leaves the variable contents where they are. You can decompress directly from the archive by calling ti_Open, then using ti_GetDataPtr and decompressing from that pointer, rather than using ti_Read.

Regarding how to reduce the RAM usage of the background, I personally would split the background into repeating sections that you can then display in a random order, rather than using a huge background with a lot of similar sections. A quick mockup I drew:


The red sections can just be regular sprites that are repeated. The green section is just the metal plate texture, not including the "seam" between two plates. Even a relatively narrow slice like this one could be tiled to fill the entire screen. The pink section would be a RLET sprite that includes the beams along the wall and the seams between plates, and has transparency elsewhere. Because RLET sprites don't include transparent pixels in their size, you could store several variants of this without eating up much RAM.


gfx_CopyRect is somewhat slow for this purpose - if you're looking for performance optimizations at some point, you may want to look into directly reading the sprite data, and then using that for gfx_HorizLine.

Anyways, it's looking really good so far - keep up the good work!

I made this after staring at your post until I absorbed the knowledge:
Code:

Which looks basically the same as what I was already doing when the USB bug became an issue, which I never uploaded because of said bug:
Code:

So that's amusing... Anyway, the best method I've found is to decompress from the flash pointer directly into a background sprite tile, which is 7684 bytes at it's largest because RLET compression is really bad on non-RLET sprites. I would've thought that the speed would be awful by how everyone loves to trash-talk the pre-M calc flash chips, but It's only slightly slower than decompressing from the RAM on my rev-L. I'll think of a fix for that soon, I have a few vague/bad ideas. However, the current decompression method means that I'll need 15 appvars for each background tile, and then more for every other sprite array I use. I'll have to do some research on pointer math (which appears to be a bunch of inline char* conversions and messy looking code), but is there a better way I should be using? I know that convimg can make a lookup table for sprites in an appvar, but I don't know how to use that information (yet).

so i ran the latest version of jetpack joyride and it worked fine, but after several runs, the screen went pale blue and my ram reset. now, whenever I run the program, my screen goes pale blue and my ram resets.

I've had that issue before too. Try deleting Jetpack Joyride as well as any appvars that go with it and then re-downloading it from github. If that doesn't work, PM me and I'll send you a different version that might.

In case it wasn't obvious, I ignored those issues so I could wait to post with the new funky stuff.

4 tins of Altoids later...



I got it to work! The FPS is abysmal due to the fact that I'm reading it from the flash rather than the RAM, but I can fix that in a few minutes and hopefully clean up/optimize what I've done. I did some big-brain stuff with pointers and I now have enough room to add code without bizzarre errors, I threw a bunch of ti_CloseAll()'s in since they have magical properties that I still don't understand, and I fixed moar grammer.

Of course, pushing this update at all was idiotic since it's not really playable for calc revisions L and under, but I want to humbly ask everyone with a rev M+ calc to try the flash-read-based release and tell me what kind of speeds you get. Just send the 4 appvars and the main program and have fun benchmarking, remember to clear your old saves manually (or just reset the calc since I've purposefully been saving them to the RAM) or just watch the fireworks. I have exams in 2 weeks and hope to get a better version and maybe something else big out beforehand, but I suck at scheduling so who knows what'll happen... but yeah, enjoy the stuff if ya wanna live on the wild side, I'm aware of a few drawing bugs that aren't showing up in the screencap and will be working on those tonight and tomorrow.

I like this update a lot; the only thing off was how slow the game ran. This is probably one of my favorite calculator games now!