Hey guys, I'd like in on this project :Dlooks like it will be a cool game after all :D
I voted TinyCraft :D
I can work on the inventory and crafting system, maybe we could use L2 for the inventory : two bytes per item (so 250 items, should be enough) storing the number of items the player owns.
I voted TinyCraft :D
I can work on the inventory and crafting system, maybe we could use L2 for the inventory : two bytes per item (so 250 items, should be enough) storing the number of items the player owns.
Shouldn't one byte be enough if you have a header to tell at which position each item is at in L2?
Here guys, I compiled all the recipes for you. This is pulled from the source code so it should all be right.Great! Added.
[...]
What is your idea for levels ? Maybe you could add it in your first post.Double post :P
Ok, it seems to be a nice system, but it will be hard to load 32x32 maps in RAM, so will there be separate areas with a loading time between ?Well even the real Pokemon Yellow game works that way (I don't know the dimensions of the areas though) and it is not disturbing at all. We'll just need a little Copy ;)
Actually, you could transfer the map in RAM to an appvar in archive, so changes would be persistent. Keep in mind that we also need to save object data as well (furnaces, workbench, etc.)Yes but first archiving a huge map is slow D: but also, when you want to make a new game, you can only play on the edited map (except if the game recreates it but then the executable will be huge). This is why I thought of an archived and non permanently editable map ;)
I personally don't see any problems with it - in fact, it's pretty much required for the game to work at all. To regenerate maps all you have to do is overwrite the existing appears anyways, since none of the data is stored within the program anyways (except maybe the current map to a buffer)Yes, but then the program will be huge (except if someone finds the agorithm to create maps) and if the program is huge, quitting it with writeback allowed takes hours.
I personally don't see any problems with it - in fact, it's pretty much required for the game to work at all. To regenerate maps all you have to do is overwrite the existing appears anyways, since none of the data is stored within the program anyways (except maybe the current map to a buffer)Yes, but then the program will be huge (except if someone finds the agorithm to create maps) and if the program is huge, quitting it with writeback allowed takes hours.
This is why I thought about this. Never need to unarchive anything ;) (except when you save the game).
And with your method, saving also requires to save the whole map (so it takes ages too), while my method doesn't need to unarchive anything, except the little savegame with items and such, and the area you are in.
Personally, I have zStart, so even writeback is fast, but for those with 83+, optimization is needed on this.
Mojang released the source, and you can find all the algorithms in there which would reduce size over using predefined maps.The predefined map I was talking about was not a map that the game would create, but an appvar included in the zip, so the program is even smaller ;)
Also, archiving and unarchiving is a reasonable sacrifice for having persistent saving. You only need to archive appvars once per map change anyways.On a full 83+, it is already a lot :-S
and you don't have to write back to the program at all.Yes, but not every shell has "intelligent write back" :(
Wait! So will this be for all ti 8* calcs? Like 83, 84+, 84+se, etc. ? And also I'm assuming in order to write and test all this code you will need the sprites...which I am please to anounce i have a bunch of them done! I'll post them in a few minutes. And they are sized correctly!!!Nope, only 8x calcs that can support Axe, so not the TI 83 (i guess), but yes, TI 83+, 84+....
I don't think that predefined maps are a good thing, because what's the point of a sandbox game if everything you build is destroy once you left the area ?Yeah, that is true. The only problem is really that archiving thing :(
Édit : very nice sprites ! But why in the last one the character is putting his hands on his head ?
here are some of the main characters sprites. It's hard to size it down to 8x8 so I did 8x16 which will make it look more like a person.Great work :D
well Hayleias are good fixes, but the fixes go out past 8 width. And I am referencing the originals for mine??? Mine aren't larger than yours
That shouldn't be an issue.Actually, when the person is taller than the trees it looks kinda weird. But sure, if belief is to be suspended go with it ^^
By having the collision only checked for the bottom 8 bytes, and the top is just displayed, it would feel a bit more realistic.
Hey saintrunner, do you think you could resize the tiles themselves, starting with the normal world, so I can see how they look in my new tilemapper? Thanks a ton ^^
DOUBLE POST! sorry lolNice :D
here is the sprite sheet so far. I think there is enough to start coding a little basic stuff. I don't know how you all want the grey scale so I'll leave that up to the ones coding this. these are just your designs :)
tell me what you think! These are as close as I could have gotten with the originals, I think they will look really good on calc!
The rest are on there way!!! GO saint! Go
(http://img.removedfromgame.com/imgs/010612.gif)
This is running fairly awesome 4scale for a 32x32 tilemap.
Here's the source attached, if anyone wants to check it out. Most of it is runer/builder's ops, I just threw it together for use in this project :PI checked it. And I saw a Full D:
Also Heyleia, if anything the tilemapper would actually go slower. It's still drawing the same number of sprites (remember, each 16x16 is actually 4 8x8's) and it also has to draw the sprites that are completely off the screen, unless I do some massive ops :PD: So this will never run on a 83+ with smooth scrolling ?
thats why I wanted to have like zelda or pokemon maps. a little scrolling but you walk of screen and come back on the other sideYeah, that is what I proposed. I think it would gain speed but not seeing further than the edge of the screen can be annoying :-\
Also Heyleia, if anything the tilemapper would actually go slower. It's still drawing the same number of sprites (remember, each 16x16 is actually 4 8x8's) and it also has to draw the sprites that are completely off the screen, unless I do some massive ops :PD: So this will never run on a 83+ with smooth scrolling ?
Saintrunner those are great for now. I'm asking around to see if anybody's figured out that map generator so I can get to writing those routines >>Well, we'll need someone who knows Axe and Java to understand the source
where is the source?Same. ???
I highly doubt the mighty Notch himself would descend to speak with such lowly mortals as us, when there are so many other people who can probably solve our problems :Peh? he spoke to SirCmpwn
"Hey Notch do you know Axe?"no I mean what the code means
public static byte[][] createAndValidateTopMap(int w, int h) {
int attempt = 0;
do {
byte[][] result = createTopMap(w, h);
int[] count = new int[256];
for (int i = 0; i < w * h; i++) {
count[result[0][i] & 0xff]++;
}
if (count[Tile.rock.id & 0xff] < 100) continue;
if (count[Tile.sand.id & 0xff] < 100) continue;
if (count[Tile.grass.id & 0xff] < 100) continue;
if (count[Tile.tree.id & 0xff] < 100) continue;
if (count[Tile.stairsDown.id & 0xff] < 2) continue;
return result;
} while (true);
}I'm more concerned about how it generates areas and pieces them together (so you don't have scattered desert in the middle of a forest, etc.)That's what I'm interested in, too, but I haven't really deciphered all of that yet >.< He uses a lot of calculations and no comments of any kind, making it quite a challenge to figure out what he's doing for much of it.
/*
* for (int i = 0; i < w * h / 2800; i++) { int xs = random.nextInt(w); int ys = random.nextInt(h); for (int k = 0; k < 10; k++) { int x = xs + random.nextInt(21) - 10; int y = ys + random.nextInt(21) - 10; for (int j = 0; j < 100; j++) { int xo = x + random.nextInt(5) - random.nextInt(5); int yo = y + random.nextInt(5) - random.nextInt(5); for (int yy = yo - 1; yy <= yo + 1; yy++) for (int xx = xo - 1; xx <= xo + 1; xx++) if (xx >= 0 && yy >= 0 && xx < w && yy < h) { if (map[xx + yy * w] == Tile.grass.id) { map[xx + yy * w] = Tile.dirt.id; } } } } }
*/That's just about all we have in terms of comments (at least in this class).// byte[] map = LevelGen.createAndValidateUndergroundMap(w, h, (d++ % 3) + 1)[0];
// byte[] map = LevelGen.createAndValidateSkyMap(w, h)[0];
Actually, you could transfer the map in RAM to an appvar in archive, so changes would be persistent. Keep in mind that we also need to save object data as well (furnaces, workbench, etc.)Yes but first archiving a huge map is slow D: but also, when you want to make a new game, you can only play on the edited map (except if the game recreates it but then the executable will be huge). This is why I thought of an archived and non permanently editable map ;)
I personally don't see the point of tracking changes; you're going to have to unarchive and archive each map anyways. It might even be harder and take longer to track just the changes, when you could just overwrite the old map with the new one completely.
(http://img.removedfromgame.com/imgs/010612.gif)
This is running fairly awesome 4scale for a 32x32 tilemap.
32x32 tilemap, 4 levels of grayscale, meaning 2 bits per tile, so 2048 bits or 256 bytes. Unless I completely botched my thinking there.....(http://img.removedfromgame.com/imgs/010612.gif)
This is running fairly awesome 4scale for a 32x32 tilemap.
Hey how many bytes is this?
1200 bytes larger? We'll have to cut that down xD
Anyways, I think I've figured out the overworld map generator. Wasn't terribly difficult, the code's just bloody long.
--Tools
wood Pick [01]
rock Pick [02]
iron Pick [03]
gold Pick [04]
rock Pick [05]
wood Axe [06]
rock Axe [07]
iron Axe [08]
gold Axe [09]
gem Axe [0A]
"wood Hoe" [0B]
"rock Hoe" [0C]
"iron Hoe" [0D]
"gold Hoe" [0E]
"gem Hoe" [0F]
"wood Shovl" [10]
"rock Shovl" [11]
"iron Shovl" [12]
"gold Shovl" [13]
"gem Shovl" [14]
--Weapon
"wood Sword" [15]
"rock Sword" [16]
"iron Sword" [17]
"gold Sword" [18]
"gem Sword" [19]
--Utilities
"Pow Glove" [1A]
"Workbench" [1B]
"Furnace" [1C]
"Lantern" [1D]
"Anvil" [1E]
"Oven" [1F]
"Chest" [20]
--Resources
"Wood" [61]
"Stone" [62]
"Flower" [A3]
"Acorn" [A4]
"Dirt" [A5]
"Sand" [A6]
"Cactus" [A7]
"Seeds" [A8]
"Wheat" [69]
"Bread" [EA]
"Apple" [EB]
"Coal" [6C]
"Iron Ore" [6D]
"Gold Ore" [6E]
"Iron" [6F]
"Gold" [70]
"Slime" [71]
"Glass" [72]
"Cloth" [73]
"Cloud" [F3]
"Gem" [74]I try it now. :w00t:
Oups sorry, there is 53 item exactly (not 63)... here a list that could be in data :a few things are uncraftable, though(e.g. pow glove and resources)Code: [Select]--ToolsI try it now. :w00t:
wood Pick [01]
rock Pick [02]
iron Pick [03]
gold Pick [04]
rock Pick [05]
wood Axe [06]
rock Axe [07]
iron Axe [08]
gold Axe [09]
gem Axe [0A]
"wood Hoe" [0B]
"rock Hoe" [0C]
"iron Hoe" [0D]
"gold Hoe" [0E]
"gem Hoe" [0F]
"wood Shovl" [10]
"rock Shovl" [11]
"iron Shovl" [12]
"gold Shovl" [13]
"gem Shovl" [14]
--Weapon
"wood Sword" [15]
"rock Sword" [16]
"iron Sword" [17]
"gold Sword" [18]
"gem Sword" [19]
--Utilities
"Pow Glove" [1A]
"Workbench" [1B]
"Furnace" [1C]
"Lantern" [1D]
"Anvil" [1E]
"Oven" [1F]
"Chest" [20]
--Resources
"Wood" [61]
"Stone" [62]
"Flower" [A3]
"Acorn" [A4]
"Dirt" [A5]
"Sand" [A6]
"Cactus" [A7]
"Seeds" [A8]
"Wheat" [69]
"Bread" [EA]
"Apple" [EB]
"Coal" [6C]
"Iron Ore" [6D]
"Gold Ore" [6E]
"Iron" [6F]
"Gold" [70]
"Slime" [71]
"Glass" [72]
"Cloth" [73]
"Cloud" [F3]
"Gem" [74]
Yes, it work ! :)wow kindermoumoute, that's one nice menu you have there Ö
We really don't need grayscale on the crafting menu. If the grayscale was taken out, there may be a possibility of the size being reduced/it running faster.I agree. And I was doing it, but since kindermoumoute has been faster than me... Nice job anyway, but I don't really like the design.
Also, is there any chance of shrinking the size of the items in the crafting menu so we can stick more in there?What you want add in crafting menu ? ???
In first tilemap (eg. 2048 bytes) modifiable with map gen
Pointer : getCalc("appvSAVE",Y1)
After that comes naturally tiles (eg. 256 bytes)
Pointer : Y1+2048=>T
(Like tile)
Then comes mob's sprites (eg. 256 bytes)
Pointer : T+256=>M
(Like Mobs)
Now come my part, with sprites of items, exactly 848 bytes longer
Pointer T+256=>S
(Like sprites)
Then items data 106 bytes (the real save start here) , each {I*2+D} are quantity of current item I
Pointer S+848=>D
(Like Data)
Now start the mistake we have others Data : last positions in map, & what you want (lets say X bytes) , and chests contents {32*2+D}*53 bytes !
Pointer D+106=>C
(Like chests)
AND finally the strings (easily modified to change langage regardless of the bytes) :
Pointer {32*2+D}*53+X+C=>E
(Like End !)
Hey guys,(http://26.media.tumblr.com/tumblr_lfi03wHdlo1qbvc38o1_500.png)
After reading through his source, I thought that the way kindermoumoute accessed the data was roundabout and not that fast or efficient, so I tried making my own. Tell me if we should keep it or not ^^
(http://img.removedfromgame.com/imgs/010912.gif)
It does, however, use the same item identification system as kinder's menu does.
(Also, I haven't put in the sprites for the weapons yet :P)
Hey guys,O.O
After reading through his source, I thought that the way kindermoumoute accessed the data was roundabout and not that fast or efficient, so I tried making my own. Tell me if we should keep it or not ^^
(http://img.removedfromgame.com/imgs/010912.gif)
It does, however, use the same item identification system as kinder's menu does.
(Also, I haven't put in the sprites for the weapons yet :P)
Well it looks like you guys don't need my sprites or spriting anymore...so good luck guys! peace out
:)
*saint wonders why they keep changing and resizing his sprites. oh well...can't be perfect I guess
Hey guys,can I have the source code?
After reading through his source, I thought that the way kindermoumoute accessed the data was roundabout and not that fast or efficient, so I tried making my own. Tell me if we should keep it or not ^^
(http://img.removedfromgame.com/imgs/010912.gif)
It does, however, use the same item identification system as kinder's menu does.
(Also, I haven't put in the sprites for the weapons yet :P)
Hey guys,That looks so sweet that I have started doubting to make my game in basic, but in Newprog instead, so I can have greyscale too. :)
After reading through his source, I thought that the way kindermoumoute accessed the data was roundabout and not that fast or efficient, so I tried making my own. Tell me if we should keep it or not ^^
(http://img.removedfromgame.com/imgs/010912.gif)
It does, however, use the same item identification system as kinder's menu does.
(Also, I haven't put in the sprites for the weapons yet :P)
Hey guys,Nice. :w00t:
After reading through his source, I thought that the way kindermoumoute accessed the data was roundabout and not that fast or efficient, so I tried making my own. Tell me if we should keep it or not ^^
(http://img.removedfromgame.com/imgs/010912.gif)
It does, however, use the same item identification system as kinder's menu does.
(Also, I haven't put in the sprites for the weapons yet :P)
----String---Data---Sprite buffer---Sprite back-buffer
--Tools
"wood Pick" [01] [000E0F070D193020] [000E030509102000]
"rock Pick" [02] [000E0F070D193020] [00000C0204091020]
"iron Pick" [03] [00000C060C193020] [000E0F0305091020]
"gold Pick" [04] [00000C0204091020] [000E0F070D193020]
"gem Pick" [05] [000E030509102000] [000A0D020D093020]
"wood Axe" [06] [041E0F0F1B306040] [041E070B10204000]
"rock Axe" [07] [041E0F0F1B306040] [000008040B102040]
"iron Axe" [08] [0000080C1B306040] [041E0F070B102040]
"gold Axe" [09] [000008040B102040] [041E0F0F1B306040]
"gem Axe" [0A] [041E070B10204000] [04140A051B106000]
"wood Hoe" [0B] [0000000C0E1F3360] [0000000C0E132040]
"rock Hoe" [0C] [0000000C0E1F3360] [00000000000C1320]
"iron Hoe" [0D] [00000000081C3360] [0000000C060F1320]
"gold Hoe" [0E] [00000000000C1320] [0000000C0E1F3360]
"gem Hoe" [0F] [0000000C0E132040] [00000008061D1360]
"wood Shovl" [10] [00000307070E1830] [0000030706081020]
"rock Shovl" [11] [00000307070E1830] [0000000001060810]
"iron Shovl" [12] [00000000050E1830] [0000030703060810]
"gold Shovl" [13] [0000000001060810] [00000307070E1830]
"gem Shovl" [14] [0000030706081020] [00000207030E0830]
--Weapon
"wood Sword" [15] [03070F5E3C387848] [03070E5C38304800]
"rock Sword" [16] [03070F5E3C387848] [0000010204083048]
"iron Sword" [17] [0000014224387048] [03070F1E1C083048]
"gold Sword" [18] [0000010204083048] [03070F5E3C387848]
"gem Sword" [19] [03070E5C38304800] [02050B562C187848]
--Utilities
"Pow Glove" [1A] [000405050F0F1F0F] [00020A0A1814100F]
"Workbench" [1B] [] []
"Furnace" [1C] [] []
"Lantern" [1D] [] []
"Anvil" [1E] [] []
"Oven" [1F] [] []
"Chest" [20] [] []
--Resources
"Wood" [61] [0000000840162FF0] [00000007BFE9DFF0]
"Stone" [62] [0000000201273E18] [0000001C3E192618]
"Flower" [A3] [0000000C0C33000C] [000C0C33333F0C0C]
"Acorn" [A4] [020400111F1F0E04] [020E1F0E00110A04]
"Dirt" [A5] [] []
"Sand" [A6] [] []
"Cactus" [A7] [] []
"Seeds" [A8] [] []
"Wheat" [69] [] []
"Bread" [EA] [0E073B1F6E7C7830] [0018046112044830]
"Apple" [EB] [021E27273F3F3F1E] [020418180000211E]
"Coal" [6C] [] []
"Iron Ore" [6D] [] []
"Gold Ore" [6E] [] []
"Iron" [6F] [] []
"Gold" [70] [] []
"Slime" [71] [] []
"Glass" [72] [] []
"Cloth" [73] [] []
"Cloud" [F3] [] []
"Gem" [74] [] []Alright guys, here is promised code. I accidentally ram-cleared all my inventory and sprite data :( so I just threw something together really quickly, kinder you're going to have to add it all back :PI like how this is looking ;D
The reason the compiled file is so large is because it has a 4096 byte buffer for the map, a 1536 byte buffer for the screens, and a ton of other data besides.
(http://img.removedfromgame.com/imgs/011112.gif)
(BTW it takes a good 2 minutes to walk clear across the map without stopping :P)
Maybe this could be modified to generate the landWe already know how the land is generated in the original game. We're going to try to port that as best we can first.
http://ourl.ca/4129/135999
(http://img.removedfromgame.com/imgs/011112.gif)Wow, nice !
(BTW it takes a good 2 minutes to walk clear across the map without stopping :P)
Alright guys, here is promised code. I accidentally ram-cleared all my inventory and sprite data :( so I just threw something together really quickly, kinder you're going to have to add it all back :PIt mean the crafting menu you made is lost too ? ???
Wow I didn't realize so many people were working on this game right now. Initially I thought it was just leafy O.OMaybe this could be modified to generate the landWe already know how the land is generated in the original game. We're going to try to port that as best we can first.
http://ourl.ca/4129/135999
I'll make the level generator, don't worry about that. I think we should stick with 32x32 maps, and with 8x8 tiles (size), because then we can have 12x8 tiles (amount) on-screen, just like the original game, and that crafting menu is awesome :D
Tinycraft is the name now, so @moderator, please remove the poll.
We already know how the land is generated in the original game. We're going to try to port that as best we can first.Oh, okay. I was just throwing around ideas :P
Actually, it is faster. In addition, I am using only the routines I have used in the other parts of the game, so in the long run I'm actually saving space.Display boxes didn't slow scrolling of items. And if you add to each string a pointer, it mean you keep strings in program, I don't see how you calculate it give to you more space ?
why removed CRAFT() argument ?is same question than :
how you plan to make the difference between INVENTORY, BENCHWORK, FURNACE, OVEN, ANVIL and CHEST lists ?This question is asked separately than item list organisation.
"STRING"=>pointer
.String is compiled in main executable.But now, we can't get pointer with an appvars !getCalc("appvSAVE",Y1)
.How to determinate string location ?.I temporary variable
{I*2+L5}
.Is the quantity of current (I) item
{I*2+L5+1}
.Is the pointer of item obtained with UNZIP and NTH routines(http://img.removedfromgame.com/imgs/011112.gif)Great work :D
As for the last screenshot do you think you could make it so you move ? It might look less slow, as in the previous screenshots it seemed to go at a better speed. :)I agree with this :P
O.O Back after one week and I see this(http://img.removedfromgame.com/imgs/011112.gif)Great work :D
But...As for the last screenshot do you think you could make it so you move ? It might look less slow, as in the previous screenshots it seemed to go at a better speed. :)I agree with this :P
Moreover, I think that it will become even slower with enemies and all, so moving by 2 pixels at once may be better ;)
I just tuned the movement to be about what it's like in the real game. Remember, you don't want it to go too fast <<
I just tuned the movement to be about what it's like in the real game. Remember, you don't want it to go too fast <<Nope, but we don't want it to be too slow either. It is not slow yet, but with all the things that will be added, it will become unplayable, and even worse on a regular 83+ without Full mode D:
Moreover, I think that it will become even slower with enemies and all, so moving by 2 pixels at once may be better ;)Yeap, I think it's a good solution.
[TOPLEFT]+[TOPRIGHT]+[BOTTOMLEFT]+[BOTTOMRIGHT]/4 -> A //average of corner values
[WIDTH]/2 //half the width will be our max/min displacement value (can be whatever)
*2 -> I //convert to positive range, save to I
rand^I //generate random displacement based on upper bound (I)
-(I/2) //convert to actual +/- range by subtracting half of the positive range
+A //add to the average of the rectangle corners
-> M //and that's the new midpoint value
M >> 255 ? 255 -> M //keep it between 0 and 255
M << 0 ? 0 -> M
M
Return@kindermoumoute, how's the menu systems coming along?I don't have much free time right now, but I can give to you a pattern :
:#Axiom(MEMKIT)
:
:
:.MAIN
:If ALPHA
:
:If WORKBENCH
:CRAFT(1)
:ElseIf FURNACE
:CRAFT(2)
:ElseIf OVEN
:CRAFT(3)
:ElseIf ANVIL
:CRAFT(4)
:Else
:CRAFT(0)
:End
:
:End
...
...
:Lbl CRAFT
:.MAKELIST5(r1)
:
:.Display "CRAFTING" & BOX
:If r1
:.Display "HAVE" & BOX, "COST" & BOX
:Else
:.Display "INVENTORY" instead of "CRAFTING"
:If CHEST
:.Shift "INVENTORY" & BOX to the right, and Display "CHEST" & BOX to the left
:End
:End
:
:Repeat ALPHA
:.Display LIST5 (& CHEST data when needed)
:End
:Return
:
:Lbl MAKELIST5
:0→I
:!If r1
:.Eg to make INVENTORY LIST
:For(r6,0,52)
:If {r6*2+PointerOfItemData}
:→{I*2+L5}
:.If there is quantity of the current item
:{r6*2+1+PointerOfItemData}→{I*2+1+L5}
:I++
:End
:End
:0→{I*2+L5}
:Else ...etc
:...etc
:End
:ReturnWouldn't it be possible to make it just withCode: [Select]:.MAIN
:If ALPHA
:
:If WORKBENCH
:CRAFT(1)
:ElseIf FURNACE
:CRAFT(2)
:ElseIf OVEN
:CRAFT(3)
:ElseIf ANVIL
:CRAFT(4)
:Else
:CRAFT(0)
:End
:
:End
...
"Hey Notch do you know Axe?"
I quickly threw together some tile sprites so that I could show my progress so far. (meaning I don't expect them to be used or anything)
(http://jacob.heliohost.org/tinycraft/img/tinycraft01.gif)
I thought I gave you all tiles to use O.OWere them 8x8 or 16x16 ?
I think 8x16 maybe a few bigger, but I made them so you can cut them to whatever size you want ???So they weren't 8x8 if they were bigger or equal to 8x16 :P
So, would someone like to do a 8x8 sprite sheet with 3 levels of grey, preferably (for 83+ compatibility) ?Look previous post, since 1.X.X 3 and 4 grayscales have no difference (I'm surprised too).
(By sprites, I mean the trees, rocks, ground etc, not the items that are already done ;))
Yes, i was here when those came, but the rock and the trees are not 8x8 :-\
Would you mind trying the rock and the trees in 8x8 ?
yeah sure thingThanks :D
Look previous post, since 1.X.X 3 and 4 grayscales have no difference (I'm surprised too).O.o 83+ supports 4 lvls well ?
@Hayleia : Here are your 8x8 rock and tree, the reason why I didn't do them that small before was because it is hard to make stuff look good smallYes, I know that. But the calculator is only 96x64 so 8x8 is better :-\
@Hayleia : Here are your 8x8 rock and tree, the reason why I didn't do them that small before was because it is hard to make stuff look good smallYes, I know that. But the calculatore is only 96x64 so 8x8 is better :-\
Thanks anyway (also, you are fast O.O)
Saintrunner, have you think about all items sprites in yours sheet ? Can you sort items sprite by there number (1-53) ?
Eg. Wood sprite is nice, but how made cloth sprite now ? Can you make a variant to all sprites needed ?
(i hope you understand what I mean :p )
Code: [Select]----String---Data---Sprite buffer---Sprite back-buffer
--Tools
"wood Pick" [01] [000E0F070D193020] [000E030509102000]
"rock Pick" [02] [000E0F070D193020] [00000C0204091020]
"iron Pick" [03] [00000C060C193020] [000E0F0305091020]
"gold Pick" [04] [00000C0204091020] [000E0F070D193020]
"gem Pick" [05] [000E030509102000] [000A0D020D093020]
"wood Axe" [06] [041E0F0F1B306040] [041E070B10204000]
"rock Axe" [07] [041E0F0F1B306040] [000008040B102040]
"iron Axe" [08] [0000080C1B306040] [041E0F070B102040]
"gold Axe" [09] [000008040B102040] [041E0F0F1B306040]
"gem Axe" [0A] [041E070B10204000] [04140A051B106000]
"wood Hoe" [0B] [0000000C0E1F3360] [0000000C0E132040]
"rock Hoe" [0C] [0000000C0E1F3360] [00000000000C1320]
"iron Hoe" [0D] [00000000081C3360] [0000000C060F1320]
"gold Hoe" [0E] [00000000000C1320] [0000000C0E1F3360]
"gem Hoe" [0F] [0000000C0E132040] [00000008061D1360]
"wood Shovl" [10] [00000307070E1830] [0000030706081020]
"rock Shovl" [11] [00000307070E1830] [0000000001060810]
"iron Shovl" [12] [00000000050E1830] [0000030703060810]
"gold Shovl" [13] [0000000001060810] [00000307070E1830]
"gem Shovl" [14] [0000030706081020] [00000207030E0830]
--Weapon
"wood Sword" [15] [03070F5E3C387848] [03070E5C38304800]
"rock Sword" [16] [03070F5E3C387848] [0000010204083048]
"iron Sword" [17] [0000014224387048] [03070F1E1C083048]
"gold Sword" [18] [0000010204083048] [03070F5E3C387848]
"gem Sword" [19] [03070E5C38304800] [02050B562C187848]
--Utilities
"Pow Glove" [1A] [000405050F0F1F0F] [00020A0A1814100F]
"Workbench" [1B] [] []
"Furnace" [1C] [] []
"Lantern" [1D] [] []
"Anvil" [1E] [] []
"Oven" [1F] [] []
"Chest" [20] [] []
--Resources
"Wood" [61] [0000000840162FF0] [00000007BFE9DFF0]
"Stone" [62] [0000000201273E18] [0000001C3E192618]
"Flower" [A3] [0000000C0C33000C] [000C0C33333F0C0C]
"Acorn" [A4] [020400111F1F0E04] [020E1F0E00110A04]
"Dirt" [A5] [] []
"Sand" [A6] [] []
"Cactus" [A7] [] []
"Seeds" [A8] [] []
"Wheat" [69] [] []
"Bread" [EA] [0E073B1F6E7C7830] [0018046112044830]
"Apple" [EB] [021E27273F3F3F1E] [020418180000211E]
"Coal" [6C] [] []
"Iron Ore" [6D] [] []
"Gold Ore" [6E] [] []
"Iron" [6F] [] []
"Gold" [70] [] []
"Slime" [71] [] []
"Glass" [72] [] []
"Cloth" [73] [] []
"Cloud" [F3] [] []
"Gem" [74] [] []
So have we decided on 8x8 or 16x16 tiles yet? If we are going to use 8x8, someone needs to convert the 16x16 tiles from the game to 8x8, otherwise, we could probably use the same tiles as the game. Either way, we do need to decide on what shades of grey to use for tiles that look similar but are colored differently.
Looks pretty great. :)So have we decided on 8x8 or 16x16 tiles yet? If we are going to use 8x8, someone needs to convert the 16x16 tiles from the game to 8x8, otherwise, we could probably use the same tiles as the game. Either way, we do need to decide on what shades of grey to use for tiles that look similar but are colored differently.
I gave it a go. These are in the same order as the image you posted, with water included on the bottom. I also included a little mock-up so you can see what a few of the tiles look like put together. I didn't fully test all of them for smoothness when tiled, but they should all look pretty good.
(http://www.omnimaga.org/index.php?action=dlattach;topic=12151.0;attach=11294;image)
Bump.
Any progress on this, now that there is a map generator and fresh new tiles ?
Great ! I can't walk on sand ? :pNo udpate ?
Great ! I can't walk on sand ? :pNo udpate ?
I know it'd slow down the tilemapping quite a bit, but maybe there's a way to make the mountains look at lot better by giving them contiguous outlined edges...
The idea would be to check the 8 surrounding tiles to test if they are mountains as well. For each surrounding tile, there would be a sprite to XOR onto a default mountain tile sprite, removing that wall/corner outline from the sprite. How plausible is this?
Here's an example:
(http://img.removedfromgame.com/imgs2/tinycraft mountains.bmp)
(The bottom 8 sprites are supposed to be inverted like that so the XOR removes them)
The top sprite is the default mountain sprite. Before drawing the tile, that would be copied to a temporary memory area. The other tiles would be XOR'd onto the temporary sprite to remove that outline based on surrounding mountain (in order: top-left, top, top-right, left, right, bottom-left, bottom, bottom, bottom-right). The result would look something more like the example I threw together below the sprites.
Obviously it would make it slower, but the question is how much slower?
You could store the map using the basic grass/stone/sand terrain, and then when you loaded the level you could do the conversion required to update all the different sprites.
That or you just change the tilemapper to look at nearby tiles when displaying a spriteThat was kind of my first suggestion there...And it would only have to look at nearby tiles if it were drawing a mountain tile anyway.
A 89 version would indeed be nice, although I wonder if in BASIC it would be fast enough? Does BASIC allow decent scrolling?Yes I know it would be hard. I first though I could do it, but then I saw that greyscale sprites are just too pretty, so I would use Newprog.
Well, the surface level would have some exclusive tiles, as would the underground and cloud. You can exclude those and have specific loading sets for each, saving a few spaces.I made that suggestion earlier, as well when I first suggested we keep the tiles under 17.
Example: Lava isn't found on the surface (as far as I've seen anyways :P), Cloud and CloudCactus are only in the clouds, and InfiniteFall isn't on the surface either. That brings it to 16 for the surface.
In this game, is there only 1 level or can the player go underground?Normally there should be a nether, the mines and the air world(or something like that). All of these should be a kind of world. So 4 in total iirc.
three underground worlds, main world, and air world. so five.In this game, is there only 1 level or can the player go underground?Normally there should be a nether, the mines and the air world(or something like that). All of these should be a kind of world. So 4 in total iirc.
There's something I may have missed but we can't stack blocks up can we? and what if we were to dig them out again?Basically, the world in minicraft is divided into 3 layers: