Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.
La shoutbox n'est pas chargée par défaut pour des raisons de performances. Cliquez pour charger.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » Terrario, a Terraria rewrite for the calculator
Kbd2 Hors ligne Membre Points: 270 Défis: 0 Message

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


1, 2, 3, 4 ··· 8, 9, 10 Suivante
Lephenixnoir Hors ligne Administrateur Points: 24673 Défis: 170 Message

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.

The game runs at 30FPS. Due to the RAM limitations of the calculator, the world is 200x100 tiles large (though I have some ideas on how to store much larger worlds).

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).

Up next:
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?
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Kbd2 Hors ligne Membre Points: 270 Défis: 0 Message

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.
Lephenixnoir Hors ligne Administrateur Points: 24673 Défis: 170 Message

Citer : Posté le 10/07/2020 16:58 | #


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.

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.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Kbd2 Hors ligne Membre Points: 270 Défis: 0 Message

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).
Dark storm Hors ligne Labélisateur Points: 11641 Défis: 176 Message

Citer : Posté le 10/07/2020 17:12 | #


The easy way to mirror a git repository:

~/my-project $ git remote add mirror ssh://gitea.planet-casio.com/Me/repo.git

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.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Lephenixnoir Hors ligne Administrateur Points: 24673 Défis: 170 Message

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?
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Kbd2 Hors ligne Membre Points: 270 Défis: 0 Message

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 , go ahead if you want to add them to the recommended settings.
Dark storm Hors ligne Labélisateur Points: 11641 Défis: 176 Message

Citer : Posté le 10/07/2020 17:22 | #


as if the newlib port isn't installed you wouldn't be able to compile it anyway.

Maybe you can add some comment on a readme with the dependencies needed to compile the project (gint, fxsdk, etc.)
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Kbd2 Hors ligne Membre Points: 270 Défis: 0 Message

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
Lephenixnoir Hors ligne Administrateur Points: 24673 Défis: 170 Message

Citer : Posté le 10/07/2020 17:29 | #


Kbd2 a écrit :
I actually found the gray settings on this forum in a post somewhere , go ahead if you want to add them to the recommended settings.

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.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Kbd2 Hors ligne Membre Points: 270 Défis: 0 Message

Citer : Posté le 11/07/2020 04:03 | #


Wondering about that 256k of unused RAM (on the GII), how would I address it?
Lephenixnoir Hors ligne Administrateur Points: 24673 Défis: 170 Message

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.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Kbd2 Hors ligne Membre Points: 270 Défis: 0 Message

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?
Lephenixnoir Hors ligne Administrateur Points: 24673 Défis: 170 Message

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.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Kbd2 Hors ligne Membre Points: 270 Défis: 0 Message

Citer : Posté le 11/07/2020 16:45 | #


Mostly done with the save system, wow BFile is painful.
Lephenixnoir Hors ligne Administrateur Points: 24673 Défis: 170 Message

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.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Kbd2 Hors ligne Membre Points: 270 Défis: 0 Message

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 I'll clean up the code and push everything tomorrow.

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.
Lephenixnoir Hors ligne Administrateur Points: 24673 Défis: 170 Message

Citer : Posté le 12/07/2020 07:54 | #


It can't overwrite a file with new data

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).

... and if I removed the file and created a new one the storage memory would fill very quickly.

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.
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
Kbd2 Hors ligne Membre Points: 270 Défis: 0 Message

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.
Lephenixnoir Hors ligne Administrateur Points: 24673 Défis: 170 Message

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
Mon graphe (11 Avril): ((Rogue Life || HH2) ; PythonExtra ; serial gint ; Boson X ; passe gint 3 ; ...) || (shoutbox v5 ; v5)
1, 2, 3, 4 ··· 8, 9, 10 Suivante

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 77 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd