epsilon5 wrote:
How is the performance currently? Does a world of that size allow for a playable framerate? Anything over 10 or so FPS would probably be enough, as long as it's consistent.
It runs okay- it's definitely playable. But it still needs ongoing work. I'm actually redrawing the entire world each time anything changes, with culling of course, but in order to have a bigger world or faster game in general I definitely need to figure out a different way to do that. I'm also recalculating the entire world light each time you place or break a block, and I'll have to optimize that too for sure.
If you look at the screenshots, any time my selection box is hovering over a spot for a while before placing a torch, that entire time is actually being spent calculating new light. It looks like I'm idle, but the program definitely isn't.
As for animated blocks (such as fire), those are still very much test features, and they definitely slow the game down.
Needs RTX 360° rotating support... er I mean this is amazing. I love how realistic the shadowing is.
Added a very, very rough first implementation of redstone.
I'm being pretty careful to only do things in the screenshot that makes it seem like it all works properly
On a different note, I am finding myself running into a size problem already - I've only added a fraction of the blocks to the game that I really want to, but it seems that when the program gets near 30kb or more on the calculator, it just won't run it (memory error), even if you have plenty of archive space. At the moment I'm looking into using a tilesheet and/or appvar, but in order to get the size down I'm not sure what I can actually do. Any advice would be appreciated.
I'm also thinking that reducing the colors and using RLET sprites might help, but idk. Surely I must be able to add more sprites and still be able to run it, shouldn't I?
I think using appvars for graphics data is probably a must for this type of program - a lot of programs operate this way.
Also the early redstone stuff looks really cool!
tr1p1ea wrote:
I think using appvars for graphics data is probably a must for this type of program - a lot of programs operate this way.
Also the early redstone stuff looks really cool!
Thanks! And yeah I'll see if I can figure out how to use appvars.
Looking good, it seems like the logic is at least somewhat functional. You're making very impressive progress, redstone is a super cool addition.
Are you building compressed? 30k is lower than what I would expect to cause issues if you're not (I might suggest making things static wherever possible if they're not in accordance with the
toolchain coding guidelines, that has solved a lot of these weird issues for me in the past). If not, having appvars to store the sprite data is the way I'd continue. Archive space seems relatively cheap, and you can always compress if you need to.
Looking forward to more updates!
In the makefile, I have both the compression and the archive set to on- so yes. And a lot of the 30k of course is coming from the sprites, so somehow there is a memory issue trying to run such a program. But you are definitely correct in that I should switch to an appvar.
Please for the love of god update your makefile and toolchain.
And please, please, please read the
Git Guidelines and
Coding Guidelines.
I’ll try. Please take it easy though I’m still learning.
That redstone thing looks promising! Also yeah Mateo wants your code to be perfect (and I assume make your life easier in the end)
. Now the next thing we know is c4ooo is gonna try to make a redstone game.
What algorithm does it use to render? I’ve been trying to do that ever since I bought the CE (two and a half years), but have given up so many times.
S/jr/W wrote:
What algorithm does it use to render? I’ve been trying to do that ever since I bought the CE (two and a half years), but have given up so many times.
You can take a look at the source code here if ya want
S/jr/W wrote:
What algorithm does it use to render? I’ve been trying to do that ever since I bought the CE (two and a half years), but have given up so many times.
As calclover said, you can view the source code on the GitHub, specifically under the drawMap( function.
If you're asking how I draw it so quickly, I'm using a simple culling algorithm that only draws block sprites if they are not obstructed by other solid blocks on all 3 sides.
If you're asking how I calculate where to draw things, basically I have a gridToScreenX( function and a gridToScreenY( function, which take an x,y,z coordinate on the map and convert it to an x,y coordinate on the screen. It's pretty simple really, just figure out how wide your blocks are in pixels, and step by half that amount to draw the next block over. Also step the screenY value by however much you need.
In other news, life has been slightly frantic lately, but I have managed to update my toolchain, and also actually backed up my computer for the first time so I could then update to macOS Catalina. At the present moment, I am in the process of switching over to appvars and tilesets. I made the mistake of trying to fit too much sprite data into an appvar a few days ago, and it wouldn't let me compile, but that's an easy fix. I just hope I won't have to use too many appvars.
Thanks! I’m still used to BASIC functionality and just barely learned C. I hope to use that in some of my programs soon. Also, I realized that it would be easier to render block by block. I was thinking of rendering a complicated 3D image, which is probably way harder.
This looks really sweet! I actually thought of this idea myself today, and googling "isometric minecraft" led me here. Keep up the good work!
One possible graphical feature: have the sky follow the same shading algorithm as the blocks; it would look more consistent. In other words, instead of the sky color actually darkening (which is probably much faster), the same lattice/mesh sort of pattern of darker pixels populates the screen wherever the sky is shown. If that makes sense...
(edit: probably should have put the following in before posting)
Also, I'm having trouble running this on a physical CE. The archive has less than 200kB remaining, but I keep my RAM totally empty (at least, as much as possible) for this very reason: running such things that are graphics- and computation-heavy. Problem is, I select the program ISO from Cesium, and the OS throws ERR:MEMORY and tells me to check for infinite recursions or loops, "such as Y1=Y1"... Any thoughts on why this is happening?
stefan bauwens wrote:
This looks really sweet! I actually thought of this idea myself today, and googling "isometric minecraft" led me here. Keep up the good work!
Thank you!!!
darkwater4213 wrote:
One possible graphical feature: have the sky follow the same shading algorithm as the blocks; it would look more consistent. In other words, instead of the sky color actually darkening (which is probably much faster), the same lattice/mesh sort of pattern of darker pixels populates the screen wherever the sky is shown. If that makes sense...
That makes sense, but that also sounds slow. I should also note that once the map is bigger the sky won't usually even be visible.
darkwater4213 wrote:
Also, I'm having trouble running this on a physical CE. The archive has less than 200kB remaining, but I keep my RAM totally empty (at least, as much as possible) for this very reason: running such things that are graphics- and computation-heavy. Problem is, I select the program ISO from Cesium, and the OS throws ERR:MEMORY and tells me to check for infinite recursions or loops, "such as Y1=Y1"... Any thoughts on why this is happening?
Yes, I am completely aware of this issue and why it is happening. The current program that I have public on the github loads all the graphical data straight into the program when I compile it, and there are a lot of sprites involved so that's why you're getting a memory error. As I've said in a previous post, I am still working on getting sprites moved over to appvars and tilesheets, which should probably fix this issue.
If I'm being honest, I am still really happy with what I have so far, but I have been too busy with other stuff lately to work on this project (and playing a lot of actual minecraft on the 1.18 Cemetech server). When I get the chance, I'll update this thread when I have some actual progress.
It's a great game and everything but how much ram does it need in order to run the game itself is huge and it takes a lot of space but if I have other programs, about 3-5 then It would say MEMORY: INEFFICIENT and I fear that I would have to delete all of my programs except for ISO.
Memory issues are to be expected, it’s still in development so I’d be surprised if you could even play it at all right now.
I’ll update you here when I fix it
I think the idea here is to test it on an emulated CE. You can do that with CEmu (not Cemu) and a dumped ROM. I would recommend making a full backup of your calculator’s contents using TiLP or TI-Connect CE before dumping the ROM. You can find instructions on how to use various ROM dumpers on the CEmu GitHub page.
What I was saying was that making the sky use the same dithering algorithm as the blocks would make the game more consistent in terms of aesthetics. I don’t know how this would best be accomplished, but there you go.
Also, global illumination when