Oh hey, I'm glad you're able to use my other background as well! It looks great, and I can't wait to try it!
King Dub Dub wrote:
...I can fix that in a few minutes...

I am too stupid to learn not to curse myself like this...

Oh, I fixed it alright, the only issue is that the USB overwrite happens now due to the fact that I could only get 6 tiles malloc'd with almost all the code deleted. I'm going to have to move all the obstacle sprites outside of the main code and read those from the flash, although that was a plan already since it allows for custom graphics. I need to figure out how to use LUT entries correctly with multiple converts in the same appvar, but I can make a temporary hack by using lots of separate appvars again for each obstacle until I have a cleaner release. I plan on saving a little read time by making all sprites RLET and saving their flipped forms as well, which will sadly increase the program size. I could always compress them and "cache" the uncompressed versions in the flash but that would cause issues if there wasn't enough space, so I'm just leaving the massive tilesets as they are for now.

'Tis update time my fellows:

What I thought was a convimg bug was just intended behavior that I couldn't reverse-engineer by myself, Mateo explained it and I still think it's gross, but I can just stop using tilesets for now until I have a stupidly optimized way to fix it.

It's faster, the zappers turn in the right directions as they do in-game, it's now impossible for missiles and zappers/coins to be spawned at the same time, the drawing code no longer overwrites past the drawing buffer, and the total project size is growing faster than the US national debt. Also, all the game assets are completely exposed, and there isn't a single sprite included in JETPACK.8xp, so custom assets are possible

Enjoy 1.7.1, looks like it's time to bite the bullet and work on the menuing stuff and converting everything to uncompressed RLET sprites that I haven't already.


I'm not dead yet but I'm getting there.

New things (no release as of now):
    - New font
    - Main menu logic done (but no shop or settings as of right now)
    - Pause menu works like I wanted it to originally
    - Numerous optimizations
    - Clean(er) header files
The next goals that will hopefully take less time:
    - Work on the explosion at the beginning, will probably be a few frames of an image without the shrapnel for speed reasons
    - Making a death screen (a real one)
    - Adding additional bits to the background that aren't present in the game's background files, e.g. the gramophone, lamp, "Do not steal" sign, etc.
I burned out on exams, and then got into a rut where I'd think "Gee, what if I did [insert large change to code] for a test of a possible speed boost/size cut?" and then just laugh hysterically and go do anything but look at a screen. I looked at the code, fixed some metadata corruption that made it uncompilable (a long and boring story) and started adding stuff.

And for those complaining that the font is 8x8 and not the normal size (10x10 with scaling) yeah I've been working on it. Because of this I also can't get the white-on-black effect either, but I'll see about fixing that later, maybe even writing a little ASM to use 16x16 fonts (after a proper first release to the archives, of course).
With all these old game over screens, you really should have some sort of Easter Egg...

All I can say is WOW! You've really made a ton of progress and the menu looks great. I have to say though, Kachow? Skibbity? Nope? you might need a language option for English. TIny_Hacker hides The explosion will certainly add a lot to the game, as well as the other items at the start. Would it be possible to add a picture of a scientist at the beginning (just for kicks since they can't really go in the game)? Also: Are you still planning to do upgrades and powerups?
Finally: Go buy yourself some altoids! You've done a lot of work and you deserve it! Very Happy
This has far and away the best graphics of any calculator program that I have ever seen!!! It is simply spectacular!!!I wonder how large the program is in total with all those high resolution sprites?
This is awesome. Smile
The polish of this game is awesome, glad it's nearly there! Also I thought the font was fine?
TIny_Hacker wrote:
I have to say though, Kachow? Skibbity? Nope? you might need a language option for English.

That's because I was tired and wanted to laugh, "Kachow" is Lightning McQueen for start, "Skibbity" for settings since I don't know what to put there, "Nope" for the shop since that's not getting done for a long time. "Calculator?" is the about bit that I need to proofread some more.
randomguy wrote:
I wonder how large the program is in total with all those high resolution sprites?

Yes.
Angry Lettuce Man wrote:
This is awesome.

Thanks, I've sacrificed a great deal of my sanity for this project.
tr1p1ea wrote:
I thought the font was fine?

I'll hold off on perfecting it then, maybe it'll grow on me, like a fungus.

Anyhoo, I pushed a commit with what I have so far on a whim, and to show that the new toolchain is completely borked. Someone deprecated my precious ti_CloseAll() that I spammed to make all my problems go away. I fixed it so it would compile but ver-9.2.1 of the toolchain cuts out a few bytes and the calc instantly resets on startup. The old toolchain works fine with the same code so I guess I'll stick with 9.1 for now.

Of course, now for the thing that I'm most excited about, and that everyone will be ecstatic to hear: I shrunk the jetpack_joyride_main.c file from 1636 to 1586 lines with a new headers file. It's super janky and the only way I can get the compiler to work is by deleting the /obj folder and re-make-ing it again, otherwise it uses the previous file to build (I can't explain that in a logical way, it's very odd) but other than that it works great! I'll be trying to force the makefile to compile stuff correctly but I'm drowning in google results so I'll be slogging around for a while. At least now people won't bug me about it now because I "fixed" it.

So blah blah blah Moar stuff soon, just fixing the lasers; If someone can tell me why the new toolchain doesn't compile right I'd be over the moon; and the current clibs work fine with the latest version of the game, it's the just the compiling that goes ape on me.
Did you read the coding guidelines that are now a part of the CE toolchain? It now tells you how you should make nice code (and should fix your makefile issues -- you should never have to touch the makefile): https://ce-programming.github.io/toolchain/master/static/coding-guidelines.html

(Here's a hint: none of your code follows the guidelines).

As for the reset, make sure you have the latest libraries downloaded and installed (as in, redownload them). If it is still crashing let me know and I will take a look.
https://github.com/KingDubDub/Jetpack-Joyride-CE/blob/5cb9cd4c6fb6e1026ab81abc43073a5e6307cc55/src/headers.h#L3



Seriously, though, you should never include a .c file ever - put your typedefs and externs in headers, and your data and functions in .c files. Including a C file will cause whatever data is in it to get compiled and linked twice, which causes issues like the ones you're experiencing.
MateoConLechuga wrote:
Here's a hint: none of your code follows the guidelines

I didn't know guidelines were added, they're a great read and I'll try to keep them in mind. I committed a functional header and now the code compiles normally, but ver-9.2.1 of the toolchain still doesn't generate a functional binary, and I redownloaded the clibs as well.

I dream of the day when I can make a large commit that isn't a bugfix without any egregious errors.
Well, now you have even more issues with the headers haha. Please take a look at this section; you shouldn't declare variables in header files: https://ce-programming.github.io/toolchain/master/static/coding-guidelines.html#what-not-to-put-in-header-files

Um. So why aren't you checking the return value of ti_Open() here Razz: https://github.com/KingDubDub/Jetpack-Joyride-CE/blob/master/src/Jetpack_Joyride_main.c#L84-L85

Please, ask questions. We even have a discord channel now. Anyway, the reason you are having a crash is because you are not checking the return value of gfx_MallocSprite (which uses the malloc() function. You really, really, really need to check that the allocation succeeded before just writing to memory. As for why this happens in v9.2.1 but not v9.1, it's because the heap shrunk by about 9KiB to account for a bug where random BSS/Heap memory was being overwritten by the OS.
I made a new commit that specifically avoids the variable issue because I got distracted with other things, mostly fixing the ti_Open() issue; which is actually working as intended since ti_Open() would return zero on failure, and passing zero to ti_GetDataPtr() also returns zero to the pointer variable, which I then check here to make sure all the appvars are found. I made a tiny function to make that portion of the code cleaner as well and went through the whole project to make all variables, function, and file names snake_case, and boy do I wish I'd done that sooner because it's so clean looking now! I'll try to get something out soon with either less malloc() or more alloca() or maybe something else, I'll need to do some research. Actually, I'll just ask before researching a bad idea: how should I allocate memory for flipped sprites? Should I use gfx_UnInitedSprite() or gfx_TempSprite? I don't want to add pre-flipped versions of the sprites and add bloat to the code unless I start having a real issue with the RAM.

I'll fix the constants later today, I just know that changing the file name and includes will break everything really badly for some reason and I don't want to make a commit without thorough testing.
You cannot use the fileioc API like that. If ti_Open fails, passing an invalid slot to any other function is undefined behavior and will most likely result in a crash. The fact that your particular usage works is because I specifically handled that edge case where the user was doing silly stuff. If the library code changes, your program will break. Use the API correctly please. You could create a function that takes a string, checks it, and then returns a pointer. You could also put the appvars that you need to open in a string array and iterate over them in a for loop.

If you want to get the extra heap space back, copy an example makefile from the latest release (there's a new toolchain/library release that fixes some minor issues btw), and add the following line to it. The heap issue should only occur if you are using the OS homescreen, which you aren't.


Code:
BSSHEAP_LOW = D031F6
MateoConLechuga wrote:
You cannot use the fileioc API like that.

Haha calculator go BRRRRRR

Well I fixed it by making the function return 0 if ti_Open() returned zero, so unless that's also undefined behavior I should be fine. I had a good reason for not iterating over the appvars, but I can't remember it so I'll try to find a nice way to do that and iterate over the malloc'd pointers as well to make sure they're valid, but I can't think of a "clean" way yet so that'll be out next. I'd like to reduce the heap usage just to be sure it doesn't do anything odd (maybe the USB/keypad issues caused by my overuse) but I'll have to see what the size tradeoff is. I've also fixed the globals (they compile, so that means it works) and threw in some small optimizations.
I hope this actually fits the standards or I'm finna lose my marbles
Merry Halloween, I have a real treat for you guys today (the trick is the pun)!



So yeah, I finished the death menu after far more of a struggle than it should've been, Barry materializes in a flash of light, there's a proper pause after the hall scrolls to the starting position, I told the lasers to go away and now the lag is fixed (they move off-screen immediately now), the about menu should have everyone listed and thanked (in no particular order), and I am now very very tired.

Enjoy the update and the diabeetus!
This looks very nice! I tried the other version from before and I liked it, although I am very bad at it it seems Very Happy
I took the liberty of compiling the source and creating a PR on GitHub (had o figure out how to use Bash tho bc I never really use it lol). There should be a PR that looks like "Add precompiled JETPACK.8xp (#3)" waiting for review. Dunno if you want that or not (also don't know if it even works -- I just compiled it, haven't tested it yet) but there it is.
You shouldn't add compiled binaries to the repository itself. Make a (pre)release for them in the releases page.
Okay, will do. Should I just close the branch and start over, or something else? (Or can I just be given write access ;D )
  
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 4 of 5
» All times are UTC - 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