Terrario, a Terraria rewrite for the calculator
Posté le 10/07/2020 16:05
2021 Casio Awards winner, thanks everyone!
Hi. I noticed a while ago there weren't any games like Terraria or Minecraft available for Casio calculators. For the past while I've been working on rewriting Terraria in C for the SH4 calculators using gint. I'm not sure when if ever I'll finish it, since it is a fairly big project, so I've decided to put it here for now.
Here are a few screenshots of the progress so far (some may be out-of-date):
Main menu
Gameplay
Inventory
Crafting
Equipment
A visualisation of a generated world (click for full detail)
The game runs at 30FPS. Worlds are 1000x250 tiles large (640x250 on the 35+E II / GIII).
The control scheme and a crafting guide can be found in the game's About menu.
This forum page is updated regularly with the latest release of the game, as well as a changelog in the comments.
If you aren't sure what an item does, feel free to search it up on the
official Terraria wiki.
Most recent update:
Jungle and a bunch of content.
Up next:
Who knows?
The attached file contains the latest build of the game, as well as instructions and a screenshot compiling script and map tool.
The source code repository as well as early builds of the game can be found at
this GitHub repo and
its Gitea mirror. Obviously, expect bugs in these early builds, though I take care to remove the major ones I find before releasing.
Due to the very large world, the save files for this game are big. Make sure you have at least 450kB of storage space before installing the addin (300kB on Graph 35+E II), and try to keep at least 300kB free afterwards. Tampering with the files in the TERRARIO folder will corrupt the save, so don't do that. The game will warn you if you have low storage space available, so that you can optimise your storage.
NOTE: You must have a Graph 35+ E, Graph 35+E II, fx9860GII, or fx9750GIII model calculator to run this game.
Fichier joint
Citer : Posté le 10/07/2020 16:33 | #
This looks good! I'm happy to see that gint is being used for such projects.
For completeness I must mention Remiweb's Calcraft which is the closest to the original game that we have.
If you don't care about SH3 compatibility (which is fine, honestly), there are a few ways to obtain more memory.
• You can first look in the heap where you have about 48k, though it is kind of buggy.
• SH4 machines have 32k of static RAM instead of 8k (I will soon provide an SH4-only linker script to allow using this properly).
• You have 8k of on-chip XRAM and 8k of on-chip YRAM, plus a bit less than 4k of on-chip ILRAM.
• Finally, there is an unused memory area of 256k (a whole half of the RAM actually), but it's used in the latest fx-9860G III so it's not a safe bet.
There might be up to ~500k of available memory through DSPs associated with a sound unit, but we don't know how to use that yet.
You can also just load stuff lazily from a file, though gint does not interface extremely well with BFile so the performance might not be high (anything related to BFile is slow anyway x_x).
A main menu and save/load capabilities.
Good luck with that! Note that to use BFile you have to call gint_switch() and then do only the BFile stuff within the switch. There is an example here.
Do you have plans for procedurally-generated terrain yet?
Citer : Posté le 10/07/2020 16:44 | #
I'm already using 40k of the heap memory to store the world tiles, and I might make the world a bit flatter so that it's wider. It probably wouldn't be a good idea to fragment the tile data into multiple locations. That 256k RAM sounds great for storing a big world - I could make 2 releases, one using the spare 256k and one for the GIII models that just uses the heap.
I was thinking about streaming the world from files, but I didn't think it would be fast enough so wasn't planning on playing around with it anytime soon.
I've noticed gint_switch messes with the grayscale timer, although gray_start will probably fix it. In any case, the saving would only happen on exit, where I wouldn't need to worry about restarting the grayscale engine.
As for terrain, right now it's making a few layers then using 1D perlin noise to randomly generate hills. I absolutely plan on implementing procedural terrain at some point, wouldn't be Terraria without some ruined houses.
Citer : Posté le 10/07/2020 16:58 | #
Yes! This is kind of an unsolvable problem. The gray engine can only be run when gint controls interrupts, and BFile can only be run when gint is unloaded. I would usually work around this problem by adding a monochrome screen during the save. I hope there are viable alternatives for you.
Do you have a source code repository? We host most of our projects on gitea.planet-casio.com, if you want to store or mirror your code there it is possible.
Citer : Posté le 10/07/2020 17:03 | #
It's currently hosted at https://github.com/KBD2/terrario, though I'd be happy to set up a mirror on gitea (I don't have any experience with mirroring repos though, so I'd need some guidance).
Citer : Posté le 10/07/2020 17:12 | #
The easy way to mirror a git repository:
And each time you push your work online, you can git push mirror master too.
For Gitea, let me know a username and an email so I can create you an account (registrations are closed because of spam issues), by PM if you want to keep it private.
Citer : Posté le 10/07/2020 17:15 | #
I should mention that you need to push the Makefile and project.cfg files or the project cannot be built from a cloned repository (but maybe this is intentional). Most syscalls are also incompatible with gint, the RTC stuff is fine in current OS versions but gint's API normally has you covered.
Your gray settings look nice, can I add them to <gint/gray.h> with the other recommended settings?
Citer : Posté le 10/07/2020 17:19 | #
Yeah, I wasn't sure if I should include the files needed to build as if the newlib port isn't installed you wouldn't be able to compile it anyway.
I actually found the gray settings on this forum in a post somewhere
Citer : Posté le 10/07/2020 17:22 | #
Maybe you can add some comment on a readme with the dependencies needed to compile the project (gint, fxsdk, etc.)
Citer : Posté le 10/07/2020 17:25 | #
That sounds reasonable, I did talk about the dependencies a bit when I had the makefile on there, I'll put the build files back on and add some comments in the readme
Citer : Posté le 10/07/2020 17:29 | #
I actually found the gray settings on this forum in a post somewhere
Interesting. Usually every new version of the engine needs to have entirely different settings, so I did not see that coming!
I played around a little bit and found that 923, 1742 has less noise and made it the default in gint since it's better than what I had so far.
Citer : Posté le 11/07/2020 04:03 | #
Wondering about that 256k of unused RAM (on the GII), how would I address it?
Citer : Posté le 11/07/2020 08:17 | #
Sorry I forgot to mention that. It's 8804000...8807ffff, the second 256k of the RAM. You can check whether they exist by testing whether 88040000 retains written values and is different than 88000000.
Citer : Posté le 11/07/2020 08:32 | #
Right, I'll have a look at it. Working on the main menu right now
Ajouté le 11/07/2020 à 14:45 :
Pointed the tile array to 0x88040000 and everything seems to be working, this is great! I guess I will have to add a couple checks to make sure the memory can be accessed properly before trying to use it. For the GII calculators this means I can have a 500x250 world (250kB), does anyone know how much heap memory the GIII models have?
Citer : Posté le 11/07/2020 15:44 | #
Well done! The heap on GIII models has around 90k of memory. But the malloc() implementation is kind of buggy so you might get the best reliability if you are able to chunk it apart.
Citer : Posté le 11/07/2020 16:45 | #
Mostly done with the save system, wow BFile is painful.
Citer : Posté le 11/07/2020 17:02 | #
I'm considering building an in-memory filesystem in gint, but the limited amount of storage makes it half useless so I'm not decided yet. On the plus side, no overwriting files, no switching out of gint. On the minus side, storage is bound by RAM size.
Citer : Posté le 11/07/2020 17:13 | # |
Fichier joint
Yeah, that wouldn't be ideal considering the save file sizes for Terrario. On the bright side, I just got the save system fully working
Ajouté le 12/07/2020 à 02:55 :
This is strange... on the emulator, everything is fine, but on my physical calculator it hangs infinitely when overwriting a save file with a different world. Loading the save after resetting the calc shows that it gets partially overwritten then just stops. Loading a save then exiting works just fine.
Ajouté le 12/07/2020 à 03:34 :
Really can't figure this one out, I've been experimenting and there is some very strange behaviour with BFile_Write. It can't overwrite a file with new data, and if I removed the file and created a new one the storage memory would fill very quickly. The only solution I could think of was to remove the old file, create a new one, and call SMEM_Optimization which crashes the addin after optimising. I'd need to tell the user to keep at least 500kB of storage memory free, and 250 if there's already a save file.
Citer : Posté le 12/07/2020 07:54 | #
Yes this is correct, it is one of the limitations of BFile. The flash ROM can only turn 1s into 0s, not the other way. You need to delete and recreate the file in order to have the sectors wiped before you can write new data. I would suggest using multiple subfiles in a folder to mitigate this effect (but no subfolders, they don't work).
Yes, and optimizing the storage memory from an add-in is a complete pain and currently categorized as "experimental". But I see you've found about that already. Check this documentation page for SimLo's experimental way to move code to RAM then reload the add-in after optimizing if you think this is the way to go. I am not yet confident in gint's ability to cope with this because I have never tested it before, so please think of it as a last resort.
Citer : Posté le 12/07/2020 08:02 | #
I was actually reading that, not sure if fxSDK can assemble .src files but I was getting 'undefined reference' errors so I gave up. Multiple files could be an interesting idea, it would also allow me to be smart and only save regions that have been changed.
Citer : Posté le 12/07/2020 08:54 | #
These .src files from SimLo's documentation are actually written for Renesas' original SuperH assembler, which is part of the tool chain shipped with the fx-9860G SDK. We usually consider this toolchain to be of lower quality than GCC, so I haven't used it in years. You can absolutely use assembler with the fxSDK, it calls sh-elf-as for the job, but the syntax is slightly different.
Here are a couple instructions that should get you through:
• .SECTION P,CODE,ALIGN=4 becomes .text followed by .align 4
• .export becomes .global
• Instead of the SYSCALL macro, you can use the C preprocessor as in gint's core/syscalls.S (save your file as *.S instead of *.s for GCC to run the preprocessor)
• Don't use ? in symbol names. "." is often used for local symbols (eg ?try becomes .try). Also a colon is missing after ?exit
• Instead of mov.l #0x80010070, r2 do mov.l .syscall_addr and later on, after the code, .syscall_addr: .long 0x80010070
• .POOL and .END can be removed, .DATA.L becomes .long