Hello! Timmy's back, but I need some help. Thanks to TIny_Hacker, I have yet again, new texture packs (tileset appvars).
I need some code to load tileset appvars in C. I've tried this:
Code:
int LoadBlocks(char *name, int headersize, int spritesize, int numsprites) {
gfx_sprite_t *ptr;
ti_var_t appvar;
int num = 0;
int offset = headersize, size = spritesize, max = numsprites;
ti_CloseAll();
appvar = ti_Open(name, "r");
ptr = ti_GetDataPtr(appvar);
ti_CloseAll();
while (num < max) {
//sprites[num] = (gfx_sprite_t*)(ptr + offset);
sprites[num] = (ptr + offset);
num++;
offset += size;
}
}
this simply does not work. I set the headers of the tileset to "MCE". I basically need code that I can call within my code that works with a offset, spritesize, etc. Even before without a header, it didn't work.
Look at this mess
Mine doesn't use a tilemap. Only a tileset that I load into a array named sprites. Then draw it with gfx_TransparentSprite(sprites[ <sprite number> ], x, y);
TimmyTurner62 wrote:
Mine doesn't use a tilemap. Only a tileset that I load into a array named sprites. Then draw it with gfx_TransparentSprite(sprites[ <sprite number> ], x, y);
This is quite literally how a tilemap works. The tilemap libs are in Assembly, so it's more efficient to use them. 
I created a minecraft terrain generator several months ago (You can find it here.) Since it's just the map, this should be exactly what you're looking for.
Also, don't forget to dig into the wiki Mateo linked.
After many attempts, sprite loading from appvars has been fixed (credit to commandz). Also, I've been bug fixing a bunch of code. I'm working on new additions to the generator, but there's still a minor cursor bug, as seen in the animated screenshot. You can double-jump to toggle flying mode.
Screenshots:
Looks pretty good man - glad you got it working.
I was wondering how much space it currently takes up on calc?
Also are you thinking of having mobs too?
The world size is 160x150 blocks.
There's 4 appvars which hold all the textures the game uses. (blocks, items, foliage, and plants)
Yes, I am hoping to add mobs to the game as well. It's been my goal since years ago, even with the ICE version which only had a 40x40 world.
Looks very cool, but I see no real-life coffee-making remote feature inside the program. Keep up the good work on this. This reminds me of the Nspire 2D Minecraft so far. (Which I unfortunately never got to try)
World Saving/Loading progress. This is basically a copy of older code, which was broken. Compression and world data saving is thanks to Beckadamtheinventor, who made code which saved the data to appvars, using compression due to large sizes.
Also, you can see an updated inventory
This time, the basic shadowing was off, so the movement appeared slower.
EDIT: Small update: Text has been corrected and centered on the New World screen.
Excellent work on the development
. How do you intend to increase the playable speed?
Alvajoy123 wrote:
Excellent work on the development
. How do you intend to increase the playable speed?
I have variables for world engine scrolling, normal walking pixel skipping and gravity falling pixel skipping. It's slower now because it's having to load sprites from 4 appvars, not always only one per screen draw. So it's slower now, but I'll find a way to optimize it.
Have you thought about some kind of caching system to reduce the need to load sprites from appvars too often or [presumably] every frame?
Wow, this looks amazing! When I say, "I couldn't have done it better myself", I'm afraid I mean quite literally: the two languages I can't not code in are TI-BASIC and (to a very small extent) ICE. Sad...
darkwater4213 wrote:
Wow, this looks amazing! When I say, "I couldn't have done it better myself", I'm afraid I mean quite literally: the two languages I can't not code in are TI-BASIC and (to a very small extent) ICE. Sad...
Hey, this started from TI-BASIC loong before I came to cemetech, and moved to ICE later. It only had a 40x40 world then. If I could do it, so can you. My code practice is also quite terrible, but it's functional. That's my values, if it functions, it's enough, because perfection doesn't come overnight. Nor is it possible with *everything*.
ICE version:
https://github.com/TimmyTurner51/2D-Minecraft-CE
I've not released a ti-basic version, but it started from basic homescreen graphics.
Go for your goals, and once you reach them, look at how far you've came, the work you put in.
You've come pretty far since your first run-in with Minecraft cloning. Nice work.
Before moving into game function & interactions, I think you need to optimize ur current progress. I'd suggest starting with compressing all your images. This leaves room to have a practically sized program. Look to increase the speed of ur current world map loading/displaying. Maybe find some help in creating a custom assembly routine. At the speed your program is currently running at, I believe adding features to the game will be frustrating difficult to do.
I look forward to future work on your project.
I definitively need to try any iteration of this project. I'm following it whenever there's a new post even though I don't post as much as before.
I uploaded another release, with a discord invite to our server!
https://github.com/TimmyTurner51/2D-Minecraft-CE-LITE-
There are still bugs, it's incomplete, but read the readme for full details!
I have made improvements to the rendering engine, so it loads only the necessary sprites into an array for a screen draw now, rather than reloading the texture for each block at a time as they're being drawn.
I've implemented an input routine thanks to MateoC, and implemented day/night cycling (although it is rather fast with changing still, and no sun and moon graphics yet).I will fix that later.
Seems to be a little faster
.
I note you're displaying debugging information on the buffer screen; I'm assuming you're using CEmu; if so, you can use "#include <debug.h>" to display debugging information within CEmu's console; it's wayย quicker than displaying debugging information on your buffer.
Keep up the good work
!
I've been trying to improve gameplay smoothness, it's doing well. There's 2 variables used with the world renderer, one for simple directional pixel scrolling, the other is the gravity pixel scrolling amount. The higher they are, the faster it is, but choppier it seems.
There is a bit of lag when it detects you've stepped a block. Also fall damage is being tested, and I was trying to get better falling gravity implemented, which isn't complete yet ofc. The red flicker has since been removed, and next is testing a death screen. Slowly progress is being made.
Progress has been slow, mostly with figuring out how to make water flow in the best way possible. There's a few more bugs to fix, including full flower breaking, but I thought it'd be great for a progress update.
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)));
}
}
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
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
