This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - kindermoumoute
Pages: 1 ... 15 16 [17] 18 19 ... 57
241
« on: January 13, 2012, 12:15:21 pm »
I know my english is bad, but here this question : 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. Fortunately we have a common language, Axe  "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 ?My idea was to get those pointer with NTH routine, and stored current list of item in L5 in this order : .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 routinesBut you probably thought something else ?
242
« on: January 13, 2012, 11:34:48 am »
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 ? Anyway, why removed CRAFT() argument ?
243
« on: January 12, 2012, 04:19:04 pm »
I looked at your code, and I must admit that your way to access to string is not smaller, not faster, but really more comprehensible than mind ! x)
Unfortunately I notice you used commands that add a lot of bytes, eg. use one of rect() or rectI() but not both (-150 bytes), same thing with Pxl-Change and Pxl-Off.
Another things I didn't understand is why you removed CRAFT() argument ? Now how you plan to make the difference between INVENTORY, BENCHWORK, FURNACE, OVEN, ANVIL and CHEST lists ?
244
« on: January 12, 2012, 01:43:29 am »
245
« on: January 11, 2012, 01:10:57 pm »
* kindermoumoute is still waiting impatiently for code.
246
« on: January 11, 2012, 01:08:51 pm »
* kindermoumoute is amazed by these codes.
247
« on: January 10, 2012, 02:23:03 pm »
Ok, I can't wait. EDIT : Can you update list of my last post with yours sprites ?
248
« on: January 10, 2012, 12:45:34 pm »
Hey guys,
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 ^^
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  )
Nice.  I didn't know you were going to make these important changes, so I'd like to see your source to mix yours improvements and mine.  But plz stop saying my program was slow, because I wasn't in full speed mode, and I had not finished testing so I was extracting real-time. The list should be displayed much faster in the end. About sprites conversion, I started with saintrunner's sprites, so we have to fill this list : ----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] [] []EDIT : now tools sprites are full.
249
« on: January 09, 2012, 06:27:41 pm »
I look back on all about data organisation of item there will be in appvar "save" : 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 !)
NB1 : I recall that I use r1, r2, r3, r4, r5, r6, I, J and L5 as temporary variable, please use them in the same way. NB2 : To return about chests, I have redesigned it and it could work with memKit axiom, and with a maximum of chests smaller than 255 x). NB3 : I can't create and test appvar until all items sprites are finished. Tell me what you think about that. 
250
« on: January 09, 2012, 03:32:19 pm »
Wow.. and what happen if : - An axiom use same token than Axe parser ? - two axiom have same tokens ?
251
« on: January 09, 2012, 12:41:06 pm »
Wow, nice ! 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 ?  (If you speak about items sprites, they're already nicely compressed in 8*8 pixels.) As I think about, did you really need to add chests ? It will be a gulf of memory...
252
« on: January 09, 2012, 01:54:05 am »
Good job runer 112 ! Thx to work on it.
253
« on: January 09, 2012, 01:52:05 am »
Nice job !
254
« on: January 08, 2012, 04:16:29 pm »
I don't think you understand me. There is 5 materials : wood, rock, iron, gold and gem. Here you changed gem, and that's pretty nice, now we have Wood (black), iron (dark gray), gold (your pretty new dark gray & light gray), gem (light gray). Now can you make another to rock ? I'm going to sleep, does anyone is motivated to convert sprites during my night ?
255
« on: January 08, 2012, 03:45:05 pm »
Nice, but you added 200 bytes with getKey command.  Now with full speed mode, is it too slow for you  : EDIT : sample dispgraph work pretty, 20 bytes less.
Pages: 1 ... 15 16 [17] 18 19 ... 57
|
Show Posts
so I just threw something together really quickly, kinder you're going to have to add it all back