Oh ok that would explain it. I got it to work though so no worries thanks for the reply

Thank you :)

I'm necroing this old post again lol. I have now ported the game not only to the playdate handheld which seems i never mentioned here but also to the vircon32 fantasy console. The playdate port was made last year and is in black and white only as the playdate only has a 1 bit screen, the game is playable also in the browser and on pc and so because i created an SDL2 implementation of the playdate api just to be able to let people play my playdate games on other systems than playdate.

The now just released Vircon 32 port is kinda crazy on its own as the Vircon 32 is a fantasy console that runs on 15mhz cpu at 640x360 and i had to optimize the game a lot sometimes even splitting up logic and drawing over multiple frames or in the case of the toady game limitting tiles used by zooming in on the game a bit

The vircon32 port is available here : https://joyrider3774.itch.io/retrotime-vircon32-version
The playdate port is available here : https://joyrider3774.itch.io/retrotime-playdate

I think I saw you found your way into the Discord server. But for posterity here is an alternate invite link that should never expire: https://discord.gg/MfAEAkhG47

~Max

@mozipha

This is what I ended up going with it’s a little messy but I’ll put it here incase it’s helpful to anyone else. I’m working with sprites so I believe I can’t just sprite[0] = sprite[1]. If you can I haven’t been able to get it to work.
Thanks again.

function remove(ref o_array, index) array n_array[len(o_array) - 1] var offset = 0 var i for i = 0 to len(n_array) loop if i == index then offset = 1 endif n_array = createSprite() setSpriteImage( n_array[i], block_image ) setSpritelocation( n_array[i], getSpriteLocation( o_array[ i + offset ] ).x, getSpriteLocation( o_array[ i + offset ] ).y + ( offset *8 )) setSpritecolor( n_array[i], getSpriteColor( o_array[ i + offset ] ) ) removeSprite( o_array[i] ) repeat removeSprite(o_array[ len(o_array) - 1 ] ) return n_array

@max_shen Thanks for the feedback!
I'll look into getting those errors fixed. Splitting the trees into two separate sprites might be hard because the tree sprites I'm using are setup to be just one full sprite. I'm working on adding more items too for the shop and chests. There's still alot I want to add to the game to make it a full experience and not just a short demo. But there's still some refining that needs to be done to the current code and gameplay for sure. I'll put the errors and improvements you suggested at the top of the list of what needs updating. Stay tuned!

This is awesome, thanks for posting! I've tried to figure out how to do this myself on past occasions, and gave up-- my math skills aren't the best.

Update: im still here lol, rn im just trying to recreate the whole game from scratch to try to make it much less glitchy and optimized and actually readable. It’s going pretty well so far

Incredible work! Your passion and respect for the history is evident.. I hadn't come across King of Sumeria before. This has been a fascinating read!

@mozipha oh I can't believe I didn't notice that thanks a bunch

woah thats nice

@mozipha said in Celqi - 3D Map Editor for FUZE:

Features that I'd like to add in the future include ... file-streaming to support larger maps, if I can get it working.

I made a change to how Celqi internally tracks object locations and an unintended result is that dynamic loading will now be a lot easier for me to implement.

There are still some aspects of the system to work out, but I think I should be able to set things up so that you can use load triggers within the map to dynamically load and unload chunks of the map. It's not perfect, since dynamic loading causes some lag and framerate dips and (obviously) can't be done instantly, but if used carefully, it should make it possible to effectively have maps of any size as long as you stay within the size limit for the portions that are currently loaded.

Also re: file write limit – the write limit occurs when the file is repeatedly opened and closed in a short period of time and not strictly when the write() function is called repeatedly (that is, it occurs when the file is repeatedly written to long-term storage and not when the file is modified in RAM). The write limit can be avoided by keeping the file open while you do reading/writing and only closing it once you're completely done accessing it.

@faz808 You can get file length by checking len(fileHandle). It's not documented, as far as I know, but len() treats the file just like it treats a string or an array. Note that you can't delete characters from a file, only overwrite, so the file length may not tell you how much usable data is actually in the file. My suggestion is to pick a particular unicode character to represent unallocated file space, use that character to overwrite any data you want to delete from the file, and then search for that character to find the end of the valid data within the file.