Wait.....so you optimized this game for battery life? O.o

-The highscore info is saved directly to the program, so no external save file.
SMC boooo. 

Nothing wrong with SMC, it means you save space/time/complexity on having to store externally.

Quote from: Eeems on January 10, 2016, 01:57:32 pm

Quote from: c4ooo on January 10, 2016, 10:54:01 am

-The highscore info is saved directly to the program, so no external save file.
SMC boooo. 

Nothing wrong with SMC, it means you save space/time/complexity on having to store externally.

Wuuut is up with that smiley face
IMO, SMC adds complexity because you must write the program back. So if you are running the program from archive, that program must be re-archived which causes extra lag when exiting.

I don't know, its in your post.

It adds no extra complexity to the program. All that re-archiving etc happens on the shell level, which is optional.

Quote from: Eeems on January 10, 2016, 04:53:34 pm

Quote from: c4ooo on January 10, 2016, 04:34:04 pm

Quote from: Eeems on January 10, 2016, 01:57:32 pm

Quote from: c4ooo on January 10, 2016, 10:54:01 am

-The highscore info is saved directly to the program, so no external save file.
SMC boooo. 

Nothing wrong with SMC, it means you save space/time/complexity on having to store externally.

Wuuut is up with that smiley face
IMO, SMC adds complexity because you must write the program back. So if you are running the program from archive, that program must be re-archived which causes extra lag when exiting.

I don't know, its in your post.

It adds no extra complexity to the program. All that re-archiving etc happens on the shell level, which is optional.

I dont see it

It adds no complexity for the programmer, but the user still has to wait for it to re-archive. For example look at phenix. The game uses smc and takes time to quit.

Blame Tapatalk.

Again, that is all optional depending on the shell and not a built in feature.

Writeback Worries:
-The code for doing this with the high scores is actually smaller and faster than using an external save file, not to mention that it doesn't add clutter to the VAT.
-If I did use an external save file and the user kept it archived, I would have to unarchive it, modify, then rearchive it anyway, so there would still be lag.
-If the program is in RAM, I'm directly modifying the source program, not the copy of it at $9D95. If it is archived, I'm only modifying the copy, so it won't be permanently saved.


As to the comment about the 48-byte thing being unnecessary or possibly more difficult than just using a graphics buffer, it is actually (again), smaller and faster. Like, way faster and way smaller. It takes no extra time to render than a graphics buffer, but scrolling it down and collision testing is a lot faster and the code is smaller.


At work yesterday, I started a routine for converting a keypress (0~56) to a letter character as shown above the button. It worked fairly snazztacularly, but now I have to implement it.