Looks cool! Would be nice if there were dirt blocks underneath all the grass instead of just a brown void, but nonetheless, great work so far.
I have vars to turn off that void, which is like a super basic shadowing system. It's also faster to use that. But technically that can be turned off, I will add options later for that.

But still I need help with the ASM rewrite part.
TimmyTurner62 wrote:
I also have a small C function I want rewritten in ASM, so I can load data from the texture appvars faster. I have no experience in this, and was wondering if anyone can help with that. It'd help the game performance-wise.


Code:
 
void LoadBlock(char *name, int16_t spritenumber, int16_t spritesize, int16_t num)
{
    uint8_t *ptr;
    if (spritenumber >= 0) {
    ptr = os_GetAppVarData(name, NULL)->data;
    sprites = (gfx_sprite_t *)(ptr + (spritenumber * (spritesize + 2)));
    }
}


Assembly doesn't just magically solve speed issues. I imagine that the compiler already generates code that's reasonably close to optimal for this function given its arguments; the issue is probably that you're using the wrong arguments. Instead of storing the name of the appvar and having os_GetAppVarData search the entire VAT for it every time you need a sprite, why not look up the appvar once and store the pointer to the beginning of the appvar data to use as the argument for this function?
Also, are you calling this function multiple times per frame or something? If so, you could probably avoid having to speed it up at all by just generating an array of sprite pointers once at the beginning of the program, and then just looking it up from there instead of calling the function again.
commandz is right in looking up a variable each frame (or multiple times per frame) would have a large penalty from a speed perspective. I agree that storing the pointer to your data file and using it + some logic to obtain the location of each block sprite you need should yield faster results, even in C.
Even better, load the sprites to static memory, which will speed things up even more, especially if the appvar is archived. Given the relatively small size of the tiles, space (probably) wouldn't be too much of a concern.
Hey once again everyone! Today I decided to post another progress update! A lot things have been done.

First, changes and new features:
- Basic necessary settings added
- In-game pause menu (in-game settings not added until normal settings are more complete.
- Languages! We have English and Dutch thus far (dutch provided by Swordgirl)
- Settings page revamp!
- More World Generation Options screen, which lets you toggle flowers, villages, etc.
- Settings save and load.
- Sprites now load in their own array, so the game loads from those rather than individual sprite data from the appvars.
- Graphics for resource loading. This is based on official Minecraft resource loading screen.

Known bugs:
- Village Generation can be a bit...broken. I'm working on fixing it asap.
- FPS counter may not be 100% accurate. Using the barebones method, it only gave 1 FPS, even though the game wasn't that slow. So I'm reworking it to take into account the render speed, game speed, etc.
- When loading a previous world, and exit, the saving/compression routine can be way too slow, freeze (requiring RAM reset), or even crash the calc completely (more rare).
- When loading a previous world, the gamemode resets to survival when it was originally creative.

Now for it in action!

Resource and settings loading, new settings GUI, and languages demo:


Improved generation screen and gameplay (testing FPS counter with 2 game speeds):
Nice work Timmy. I believe you said you've added villages, any chance you can share a screenshot of that?

Also, I imagine it would be pretty easy to check if a flower is 2 high, and if so delete both blocks of it when water washes it out. But I don't know how you're storing things.
Nice work on this! I assume your "sprites now load in their own array" change meant that you got some pretty large speedups, as has been discussed in the past?

The GUI for the new settings menu is particularly nice as well, I really like the sidebar and main view kind of layout. One change I would suggest making though is to have the menus only display boxes for the number of boxes that are available--under "Gameplay," there's one blank box that doesn't appear to fulfill any purpose.

Looking forward to more updates! It's good to see all of this coming together.
Thanks for the feedback!

Well, I've noticed a small amount of speed improvement. I am hoping to soon give those empty settings some fulfillment.

Village: (also testing smoothness and water, which I noticed a bug with lol)


EDIT:
I've thought of pausing progress, I did so for around 2 weeks now. However I think it's best I keep going.
I saw Michael2_3B's awesome looking isometric minecraft, and was stunned with the shadowing. I would like to have something like that, because this project is in dire need of shadowing. This is a subject that I should've talked about more before, even in the project's ICE stages. Does anyone have ideas for shadowing given the world is a 2D array? As you all know, this doesn't use a tilemap, as I've gone too far with too many rewrites to rewrite again, but keep pushing on with what I already have.
Mainly what I'm asking for is, does anyone have maybe a simple schematic, diagram if you will, on a straightforward shadowing method. Maybe a basic explanation. This may seem like an impressive project thus far but do note I don't easily understand big, complicated sentences, nor am I actually that smart. Coding isn't my best strength but I am proud of what I can do. I'm sorry to disappoint.
Hey all, progress is still paused technically, as I've been working full time at a job. However, I want to dabble back into this project, and I do have a question. Does anyone have suggestions on how I can make a double-up keypress to toggle fly mode? Because the way I have it now, it toggles back off and on by just holding up. I can't think of a way to check for a double keypress that won't toggle when you're holding it to fly up.
A double keypress is just checking if a key has been released a certain amount of time before another press.
TimmyTurner62 wrote:
Hey all, progress is still paused technically, as I've been working full time at a job. However, I want to dabble back into this project, and I do have a question. Does anyone have suggestions on how I can make a double-up keypress to toggle fly mode? Because the way I have it now, it toggles back off and on by just holding up. I can't think of a way to check for a double keypress that won't toggle when you're holding it to fly up.


Like what Mateo said, you'd probably want to have a timer that would check if the 2nd key was pressed within a certain amount of time after it was initially pressed.

Also, this project is looking really great! I think I missed that last screenshot, but I'm really impressed at how far it has come since when you first started. Keep up the great work!
Tim it seems like the FPS isn't increasing at all. Have you tried removing smooth scrolling?

Great work on the project it's coming together nicely!
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 2
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement