Well now I can't edit the old post now without the context getting messed up, gosh darn you two for being so supportive!

Seriously though, thanks for showing interest! That really helps keep me going, especially since I just fixed the thing with the USB and did some accidental optimization.

Do I really need to keep linking the repo?...

If you check, you'll see that github was fighting me and stuff has been pushed oddly (but it works). The problem was that the missile warning icon decompression couldn't come after the zapper decompression, or something. I guess I'll blame the compiler since it did drop a lot of bytes from somewhere once I organized the decompression section, so feel free to build the latest source if you want. No new visuals as of yet. I've also realized that I have to make death animations, so I can probably make some more lazy sprites and good code and make better sprites later (if I don't get obsessed and make yet more good sprites that stretch out the development time).
Looks good so far! The one suggestion I have is to make the background have some kind of parallax scrolling effect, as based on the screenshots, the background and screen objects scroll at the same rate, which makes it look like they are on the same plane.
epsilon5 wrote:
Looks good so far! The one suggestion I have is to make the background have some kind of parallax scrolling effect, as based on the screenshots, the background and screen objects scroll at the same rate, which makes it look like they are on the same plane.
They are on the same plane, technically. Coins and zappers don't move, technically Barry is running and everything else is still. Lasers, missiles, tokens, and powerups have their own movement though.

Also, that bug with the decompression? It still exists, and moving it or adding decompression for the laser sprites I'm working on causes all sorts of weird stuff. The USB always breaks, but depending on where I put the missile section the compiled size can change dramatically, the keypad can stop working, calc can freeze, and the homescreen remains uncorrupted (which is not normal). I'm pretty sure that it has something to do with the memory I'm mallocing, but the examples don't list how to free sprite arrays, by which I mean:

Code:
sprites[i] = gfx_MallocSprite(k, h);

How do I free those arrays afterwards? Calling a single pointer works, but a for() loop crashes the calc as soon as it runs.

Code:
//this works:
free(sprites[0]);

//this doesn't:
for(i = 0; i < 2; ++i)
{
     free(sprites[i]);
}
[Shameless progress bump]

Aight, so I've done some more things, and I've fixed the free() bits; turns out that I was using a variable for decompression that technically linked to everything (the code compiles much smaller with it for some reason) so freeing it was freeing all sprite variables, so I've fixed it so now it only frees all the sprite arrays, which frees it in turn. CommandBlockGuy has told me that there is some weird behavior with large programs, which I've found some vague references to in some irrelevant posts. I've been working on the laser animations, which has basically just been me making a butchery of Gimp's functions and proving that I'm not an artist. I might upload some screenshots later, but right now I need to deal with the latest crisis.

I've got the program working even with the freezing and USB errors, but since I've been dealing with it by unplugging the calc and rebooting, it's been getting more and more buggy without any improvement. The calc now decides that it would like to live as a plastic brick until it restarts after a few minutes and clears the RAM. I obviously can't release this mess, and I can't keep trying to live with these bugs, so I'm moving my sprites to appvars. I'm going to be spending my night working on re-writing the convpng.ini as a convimg.yaml, hopefully that won't take too long.

UPDATE EDIT:

So I have good news! The appvar conversion took nearly all of my sanity last night, but I got the yaml remade and everything works! The two missile decompression bits for the "warning" and "incoming" icons aren't breaking anything anymore (that I acn tell) and the lasers and missiles will probably be getting finished animations soon!

And now for the bad news: NOTHING WORKS AND I'M ALMOST OUT OF ALTOIDS.

So now there are 4 decompression bits that are breaking the calc, and it's still freezing on exit and crashing after a random amount of time. So as of now, the only obstacles I can load are the missiles and some of the laser animations. What isn't working so far:
1. Coins
2. Zappers (both parts)
3. 1/3 of the laser animations

The code itself is commented out but updated to the repo now, building it will work and run fine but only missiles will appear after a while since I disabled the spawning loop (the missiles don't have sprites but the corruption doesn't crash the calc). Here's what it looks like:

Code:
    for(i = 0; i < 4; ++i)
    {
        //decompressing coin spritesheet:
        decompressorVar = gfx_MallocSprite(12, 12);
        zx7_Decompress(decompressorVar, coinSheet_tiles_compressed[i]);
        coin[i] = decompressorVar;
    }

    for(i = 0; i < 3; ++i)
    {
        //zappers:
        zapper[i] = gfx_MallocSprite(18, 18);
        zapper[i+3] = gfx_MallocSprite(18, 18);
        zx7_Decompress(zapper[i], zapperSheet_tiles_compressed[i]);
        gfx_FlipSpriteX(zapper[i], zapper[i+3]);
    }

    for(i=0; i < 8; ++i)
    {
        //mallocing full electric array:
        electric[i] = gfx_MallocSprite(32, 32);
    }
    for(i = 0; i < 2; ++i)
    {
        //zapper lightning:
        zx7_Decompress(electric[i], electricSheet_tiles_compressed[i]);
        gfx_FlipSpriteX(electric[i], electric[i+2]);
        gfx_FlipSpriteY(electric[i], electric[i+4]);
        gfx_RotateSpriteHalf(electric[i], electric[i+6]);
    }

    //prepare laser sprite sizes:
    for(i = 0; i < 6; ++i)
    {
        laser_firing[i] = gfx_MallocSprite(30, 37);
    }
    //laser and powering up animations, also adds flipped ones:
    for(i = 0; i < 3; ++i)
    {
        zx7_Decompress(laser_firing[i], firing_tiles_compressed[i]);
        gfx_FlipSpriteY(laser_firing[i], laser_firing[i+3]);
    }

    ...

    for(i = 0; i < 4; ++i) free(coin[i]);
    for(i = 0; i < 6; ++i) free(zapper[i]);
    for(i = 0; i < 8; ++i) free(electric[i]);
    for(i = 0; i < 6; ++i) free(laser_firing[i]);


I discovered that not freeing the sprites doesn't have any visible effect, so there may be an issue there somehow that already exists. The move to using appvars has no effect either, although the program size is down to 4628 bytes of pure code (so ~6.5 kb are compressed sprites, I need to fix that). I have a hunch that I'm doing something weird with the flipping, since the decompressorVar was leaving a pointer trail everywhere, maybe my flipping things is sticking pointers where they shouldn't be too, and I'm freeing some arrays twice. I'm going to keep working on the obstacles and menuing, but if I can't find a workaround/fix for this I don't know how I can release it yet.
Well I proved that I am stupid, so I'm going to double post (*dramatic drum noise*) so that everyone will be aware. Apparently most of the original issue was with decompression, and how data was being stored. How this was affecting me and what the actuall effects were, I can't exactly be sure. So far I've seen:
-The keyboard stops working (may function if USB is disconnected).
-The calc freezes entirely (may function if the USB is disconnected).
-The USB stops sending/receiving data until the calc is power-cycled or reset.
-The calc crashes upon USB activity, normally when receiving any data.

I have solved all the problems by simply removing the appvars and compiling the code with the sprites while compressing the code normally, which has cut it down from the original 14 kb down to 9.8 kb, with the appvar code being 400 bytes smaller. The extra 400 bytes is worth the functions. I've updated the repo and will be implementing some of the unused animation code next update, with screenies as well. I don't want to say it'll be easy, since that'll jinx me again.

Quote:
I know I did say I wanted it done by October, but clearly I was wrong. I have made good progress, but bugs and learning curves haven't been helping ... I'm still fairly new to C, so progress is agonizingly slow. I've been getting faster and better lately ... it should be out soon, absolutely before Christmas
One week counting today from Capitalist Day. Time to make some gross (but speedy) code. I keep trying to experiment with new optimizations and make 1337 code, but I'm too noob for that, so here's to production!
Jetpack Joyride has been my favorite mobile game ever since I played it on a Windows 8 computer in 2015 or so. This seems like a very faithful, well-optimized port so far, so I'm certainly excited to see how it looks and plays when it's completed!
Today I'm going to that "NOT ramble on" thing that I'm not good at.


I hope the lasers look nice, I spent way too much time on making them perfect.

The stuff I did-gone-done:
    -Added some pew-pew lasers
    -THE USB BUG IS NO MORE
    -Optimized the code by removing excess variables and drawing functions
    -Added RLET sprites where applicable
    -Changed variable names to be easier to read and keep track of
    -Corrected grammar
    -Cleaned up file names and header files
    -Found many wrong ways to code that I'll avoid from now on
    -Added moar bugs to fix this afternoon
    -Discovered the positive effect of mocha's and sundry caffeinated beverages
veevyo wrote:
Jetpack Joyride has been my favorite mobile game ever since I played it on a Windows 8 computer in 2015 or so. This seems like a very faithful, well-optimized port so far, so I'm certainly excited to see how it looks and plays when it's completed!

Out of the ~688 lines of code, about 610 lines are functional. A ballpark guess would be that I've vetted out a few thousand of lines of code to streamline about 120 of those lines. The remainder completely negate the previous optimizations. I hope to make this as faithful as possible, although the limitations of the calculator might cause problems. I still don't know if that was a waste of time, since I've clearly had some good results.

Counting today, I have 2 days. The code might be gross, but I have some easy optimizations left to make that might grab me an extra frame or two.
"U is ded lol' Mr Green

Looks very polished and is running great. Also the lasers look awesome!
This is the worst line of code I have ever seen:

https://github.com/KingDubDub/Jetpack-Joyride-CE/blob/master/Jetpack_Joyride/src/Jetpack_Joyride_main.c#L44

Never use globals. Ever. They are generally slower, larger, and horrible for coding readability.

Keep up the good work Smile
This game is SOOOO awesome!
King Dub Dub wrote:

What needs to be done:
2. Make Barry die
-animations for death by zapper
-animations for death by missile
-bounce corpse around after death
-make a "health" system where shields add 1-5 points depending on upgrades

3. Powerups
-make all the powerups
*cash dash
*rocket time
*boost
*shield
**health system, shields only spawn at 1 health and can add more depending on upgrades

4. Vehicles
-all of them
-S.A.M. is considered a vehicle but I don't know if I'll have room for it later on

5. Custom graphics for characters, lab environment, and scientists
-graphics will be stored in an appvar with the defaults hard-coded as place holders
-should make a menu system to select which sprites from which appvar to use for each object

6. Make scientists that you can torment

I am so psyched for all this awesome stuff! (Especially the S.A.M hides) I also can't wait for death animations, for some reason it bugs me to quickly cut to "U IS DED LOL" and I don't know why Razz
Anyway, awesome work, and keep it up! This is looking great so far, and it is already one of my favorite games to play even in the development stage! also, don't forget my favorite character, flash
The lasers are super cool, and hard! Evil or Very Mad
Thank you for listening to the daily moral boost and encouragement show! This is made possible in whole by myself
MateoConLechuga wrote:
This is the worst line of code I have ever seen:

https://github.com/KingDubDub/Jetpack-Joyride-CE/blob/master/Jetpack_Joyride/src/Jetpack_Joyride_main.c#L44

Never use globals. Ever. They are generally slower, larger, and horrible for coding readability.

Keep up the good work Smile
The toolchain moved to LLVM 4 days ago, how did you expect me to keep up with that and keep working on this too?!

Seriously though, I'll get to work on updating, I've been using that weird install ever since July when someone deleted the submodules and commandz had me build them manually. It'll be nice to move those uint's back in their for() loops again, I didn't know how much I missed C++ functionality, they'll be some serious code cleaning come January!

Also thanks TIny for the good vibes! I'll repay you by leaving "You is ded lol" in the game for all eternity! maybe I'll make a setting or a random chance for it or something...

Also S P E E N

I'll push the repo with some other stuff, I need to make some workarounds for RLET sprites to bring down the program size (also it's convimg issue #69, say it with me now: NOICE). The sprites took 30 minutes to optimize by hand so I'll probably spend a few more hours on them later.

7 hours, 05 minutes 'till Capitalist Day...
Other suggestions for improving the code, King Dub Dub:

* when iterating on arrays, never use constants, let alone number iterals. Those are good for defining array sizes; however, if you evolve the definition of the array later to use another constant with different value, without changing the iteration loop's bounds (because you simply forget, we're all humans making mistakes !), you'll easily create memory errors such as buffer overruns and uninitialized memory usage - IOW, security issues.
Use safe expressions of the form sizeof(array) / sizeof(array[0]) instead. Many code bases use a macro for that, named e.g. ARRAY_SIZE.

* despite the usage of constants at other places, which is already good as I wrote, there remain too many magic numbers, e.g. 6001, 641, 1467.
Ironically enough, I'd just decided to do that last night before going to bed to dream of gumdrops and candy canes and fancy M.2 SSD's. I've spent my time fixing those numbers, all those magic numbers have clear #definitions (e.g. MISSILE_ORIGIN for initial X-coords) and I've changed all the formation arrays and their loops to use a FORMATION_NUMBER value (also defined) that I can change at will.

I would've also shrunk the code by turning all my tilesets into individual sprites with as much extra size shaved off (a lot of the missile sprites are way less than 55x35), but after spending a lot of time setting it up I compiled it and discovered that it added to the compressed size, so that was a waste...

I'll be working on increasing the difficulty, since apparently people are building and playing from source, so it'll be a bit more interesting in the meantime.

Also, I'm not going to continue to string anyone along, so no more setting up deadlines. I will make a goal for the next repo push, I will learn how to do it at my slow pace, I will become unhealthily obsessed with what I think *might* be a tiny optimization that will add 30+ bytes after I spend ~20 minutes trying to get it to compile. Yell at me if I'm being slow, I have the attention of a 4-year old on crack and need to be reminded to eat on a daily basis especially with Christmas break, I can go days without meals now with all the chocolate I have. Until then, I need to optimize where I can since I had an "insufficient memory error" which made me realize that maybe I had an issue (I just needed to archive some stuff, but it was still an eye-opener).
Quote:
Ironically enough, I'd just decided to do that last night before going to bed to dream of gumdrops and candy canes and fancy M.2 SSD's. I've spent my time fixing those numbers, all those magic numbers have clear #definitions (e.g. MISSILE_ORIGIN for initial X-coords) and I've changed all the formation arrays and their loops to use a FORMATION_NUMBER value (also defined) that I can change at will.

Good.
Don't forget to use local i variables for iteration, as pointed by Mateo, since they're much more efficient than that ugly global i variable, and change the iteration bounds to sizeof()-based expressions.
King Dub Dub wrote:
I'll be working on increasing the difficulty, since apparently people are building and playing from source, so it'll be a bit more interesting in the meantime.

That took two days due to my attempts at making multiple awful functions and eventually optimizing it down to this:

Code:
        //very small bit of code to increase speed with a decreasing frequency over time, max of 12:
        if ((incrementDelay >= ((scrollSpeed - 5) * 250)) && (scrollSpeed < 12))
        {
            ++scrollSpeed;
            incrementDelay = 0;
        } else {
            ++incrementDelay;
        }

During my tests I was testing the speed and my brain decided that I should hit [del] to pause the game. The idea for a pause menu hadn't even crossed my mind yet, so after staring at my finger in disbelief at it's apparent autonomy, I went to work for a few hours making some simple code, and then some simple sprites, and then some optimized sprites, and then fighting SwapDraw(), and then throwing away all my sprites and only keeping the buttons. 3 hours of code after that mess and I had something I'm proud of:



This is the superior update, as it adds more buttons. I hated this more than any other part of the project, so I'll be function-ifying it all and re-using everywhere. I'm also maxing out the RAM, so I'll need to streamline the sprites and work on some smarter dynamic allocation, which means I'll have to go back to the appvar problems again for external zx7 and decompression, and hopefully the USB bug won't hit again (and before you ask, no I can't make the menu take up less space, I'm trying to make it as awkward as necessary to discourage pause-buffering strats and still be useful).

Also TIny is now head of marketing and stuff, he made that neat userbar himself and a sick Vysion background.

EDIT: I spent last night prototyping some sprite optimizations by making custom arrays, apparently the new toolchain compresses and adds them much better, the ZDS version added massive bloat, so now it's ~60 bytes smaller and ~3000 bytes of RAM usage. Now I have almost 4000 free bytes to work with (I don't know the average amount of free RAM but I assume everyone archives their stuff). Also the buttons look nice and compress better too.
Well it's a big update so double post it is!

New stuff:
    -Added game saves between closing/opening the game
    -Added highscores
    -Made distance, best distance, and coin counters take up more of the screen and irk me further
    -Used structs to consolidate variables under a few pointers for smaller read/write code for appvars


As you can see, exiting via [clear] doesn't reset the gameplay, while retry and quit do. Quit just resets save_data.distance (previously just "distance") to zero, flagging the save data as irrelevant since there is no game in progress. It just loads everything fresh and rewrites the save when exited again. The appvar is named "JTPKDAT" and clocks in at 258 bytes, it's unarchived by default since I found that resetting the calc is easier than searching through my appvars to delete it.

So basically, it looks like a real game now, and I say that without sarcasm.
Wow, the project is coming together quite nicely!
Keep up the good work :p
This game looks really fun! How soon will the first version be done?
Ver 0.14.0 is a buggy mess, please use 0.14.1 for fixes.

randomguy wrote:
This game looks really fun! How soon will the first version be done?

\_(ツ)_/ I dunno; I'm good at coding, not time management.



BUT HE GO SPEEN NOW! AND GFX_SWAPDRAW() IS BEING ABUSED!

So the big update is that death is now a painful reality in the game, and it comes with flying corpses and jetpacks and semi-optimized code. I also set up the screen to fill with yellow or red if you died to a certain obstacle, and then SwapDraw()'d it on 'n off the screen. Oh, and remember when I restructured all the arrays into arrays of structs? Of course not, I spent nights on that alone and it was awful. I've now restructured it again with structs of arrays and variables and renamed some variables for clarity. Also fixed some egregious grammar. It saved barely any space but I kept the compressed size under 21 kb (20897 on-calc) so that's nice. I've probably spent most of my time testing and debugging my builds, making sure that everything flowed like the game was hard. Current plans are to work on the death-menu/game-over screen and then work on the big explosion for the main menu (I'm not looking forward to it even though it's just another custom physics engine). That and some optimizations should be between the next update, and then I'll start calling this a game, and if I'm really feeling optimistic, I'll add all those powerups who's physics and rendering I've been testing instead of what's actually relevant.

Also TIny_Hacker has been promoted to head sprite-ripper, since he managed to figure out that HalfBrick is using it's own proprietary RAW image format and using it for textures; he wrote a guide for ripping them, but it uses a MacOS-specific application that also costs money, so there's no way I'm doing that (until I find an alternative, TIny keeps his job). He also made a nice icon for use with shells such as Vysion SUBLIMINAL MESSAGING. Big thanks to him for his help!

Oh, and a disturbing amount of people have been downloading my repo (you poor souls) and building it for tests. Due to the amount of people who can't get it built correctly and want to try the beta, I've made a release of version 0.14! Yes, I've made 14 code uploads and I'm still nowhere near done! I'm not very fast, but boy am I persistent. Anyhoo, go crazy, but don't share them around since I don't trust myself to write good code yet. Remember to delete your old save data appvar JTPKDAT, since old versions save in a different format than I use now.

And that concludes my capstone essay.
wow!, I really like this update, especially the dying part (not that I want to die in the game, but it is cool when I die). Btw, thank you for releasing a built version, because it was kind of time consuming to build it myself! I also saw that when the game first started up after a death, there was a pale yellow rectangle across the screen and it glitched a lot, but it didn't reset my ram and it went away after 30 seconds.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 4
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement