Seuls les membres ayant 30 points peuvent parler sur le chat.

Forum Casio - Projets de programmation


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

Terrario, a Terraria port for the calc

Posté le 10/07/2020 16:05

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 a port of Terraria for the fx9860GII/Graph 75+E 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:
Main menu


Gameplay




Inventory


Crafting



Make sure you have at least 350kB of storage space before installing the addin, and try to keep at least 250kB free afterwards. Tampering with the files in the TERRARIO folder will corrupt the save, so don't do that.

The game runs at 30FPS. Worlds are 1000x250 tiles big. Manipulation is also done via an arrow-controlled cursor, since we obviously can't plug a mouse in.

Current control scheme (Also found in MANUAL.TXT)
World:
4, 6: Move
8: Jump
2: Drop through platform tile
7: Delete tile
9: Place stone tile
Arrows: Move cursor
[MENU]: Exit
[SHIFT]: Inventory
[ALPHA]: Crafting
[OPTN]: Capture the VRAM, used to take a screenshot

Inventory:
Arrows: Move cursor
F1: Take/place an entire stack
F2: Take a single item
[DEL]: Delete item in slot
[SHIFT]: Exit
[ALPHA]: Crafting
[OPTN]: Capture the VRAM, used to take a screenshot

Crafting:
Left/Right: Scroll through recipes
[EXE]: Craft
[SHIFT]: Inventory
[ALPHA]: Exit
[OPTN]: Capture the VRAM, used to take a screenshot

Most recent update:
A crafting system, and platforms!

Up next:
Entities.

The attached file contains the latest build of the game, as well as instructions and a screenshot compiling script. 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 many bugs in these early builds.

I plan on updating this post fairly regularly to keep up to date with my progress.
NOTE: I don't think this will run very well if at all on SH3 models. The way I store worlds is not compatible with GIII-series calculators, if you have one of these and are interested in the project leave a message and I can build a version that is compatible (the release version of this game will also have a version for the GIII).

Fichier joint


1, 2, 3, 4 Suivante
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 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?
Kbd2 Hors ligne Membre Points: 91 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: 18201 Défis: 142 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.
Kbd2 Hors ligne Membre Points: 91 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 Membre d'honneur Points: 11109 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: 18201 Défis: 142 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?
Kbd2 Hors ligne Membre Points: 91 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 Membre d'honneur Points: 11109 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: 91 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: 18201 Défis: 142 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.
Kbd2 Hors ligne Membre Points: 91 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: 18201 Défis: 142 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.
Kbd2 Hors ligne Membre Points: 91 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: 18201 Défis: 142 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.
Kbd2 Hors ligne Membre Points: 91 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: 18201 Défis: 142 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.
Kbd2 Hors ligne Membre Points: 91 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: 18201 Défis: 142 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.
Kbd2 Hors ligne Membre Points: 91 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: 18201 Défis: 142 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
1, 2, 3, 4 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
Pour coloriser votre code, cliquez ici.
Sinon cliquez sur le bouton ci-dessous.
: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 v42 © créé par Neuronix et Muelsaco 2004 - 2020 | Il y a 34 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