0 Members and 1 Guest are viewing this topic.
Hayleia > Originally there was no prizes to win with the zContest (it was purely honorific), but Contra kindly managed to find us sponsors that agreed to gives us free ones. So I'm sorry if you don't really appreciate the TI 76.fr, but keep in mind it was better than nothing.
The choice was made by TSP promotion, and come on, I'm sure it can still be useful to anyone in your entourage :p
The TI 83-like aren't that bad (unless you're only programming in Axe, which unfortunatly seems to be the case). I started programming with a TI 82 STATS and I keep try to cross-compile my asm projects so they can run on both 83&83+.
Maybe it's time to switch to asm
Well in fact, I tried ASM before Axe, but failed miserably so I chose Axe instead.
Optimised ASM programs can be much smaller than Axe ones, further more if you uses some compression (RLE etc...).I'm pretty sure Pokémon Topaze can fit in 27ko (the original Pokémon Blue fits in only 1Mo, using lot of compressions methods, even if the GB hardware help to handle sprites and such).
In fact I started my own adaptation of pokémon to the TI 83/83+ : Pokémon Monochrome, it's not as developped as Pokémon Topaze but with the tilemapper, menus and battles almost finished, I'm currently at ~10ko (and without using any compression). By the way, I think I'm using one or two tiles/sprites from your project, I hope you don't mind... (It's a bit off-topic but I haven't planned to start topics everywhere about it unless I'm sure to finish it...)
Did you tried asking some help ? ASM is kind of hard when all you've ever programmed in are high-level langages (basic), but once you understood some concepts (pointers...) and learned how to use the main instructions, it becomes way easier. There are also a lot of libs to help you making some nice games fearly quickly (I'm using GBA Lib 2 (which looks a lot like GBA Lib 1), mainly because its mapper is way better than mines).
Nope, It has too much data -.-°Even the map itself already takes more than 10 000 bytes.
And no, I don't mind you using some of my sprites, I stole some from tifreak (with his permission) so I won't say anything to anyone using mine
Well I understood pointers (that helped for Axe ) and know what the main instructions do but I don't know how to do what I want then There is absolutely no command for nothing. That is of course an advantage, but it is also a drawback sometimes. At least, thanks to the basic knowledge I acquired in ASM, Axe became very easy to pick up
Quote from: Hayleia on March 14, 2013, 01:11:40 pmNope, It has too much data -.-°Even the map itself already takes more than 10 000 bytes.All maps are grouped together ? I think you could gain a lot a space by dividing it into smaller parts and/or using some compression (the easiest one is RLE).
Quote from: Hayleia on March 14, 2013, 01:11:40 pmWell I understood pointers (that helped for Axe ) and know what the main instructions do but I don't know how to do what I want then There is absolutely no command for nothing. That is of course an advantage, but it is also a drawback sometimes. At least, thanks to the basic knowledge I acquired in ASM, Axe became very easy to pick up There are many rom calls which are very useful and aren't that slow (in my case I'm mainly using maths rom calls so I can stick to the originals formulas during battles). I think the only thing you really have to understand is how to interact with the LCD (using pre-existant routines or not, such as _ionfastcopy). Once you know how to draw sprites, that's pretty much it, you're ready to program great games.
Yeah, the map is in one block. Why would dividing it in small parts take less space ? And how to use RLE on a map that takes values between 0 and 170 ?
The real problem was that the routine I found (don't remember where) that handles the keyboard was a pain (used groups of keys or I don't know what)
Aww man, I just looked around in my ASM folder, reading some old code, and it brought back so many memories, when I was full of hope, thinking about coding Pokemon Topaze in ASM And I just ran that scrolling-map program again, it really works well and all I think I should try ASM again some day, I just need to find a proper routine to handle keys
Quote from: Hayleia on March 14, 2013, 02:11:57 pmYeah, the map is in one block. Why would dividing it in small parts take less space ? And how to use RLE on a map that takes values between 0 and 170 ? Because I believe you've filled the space between maps with 0 just to make sure that when we scroll near the border of a map we don't see another one, no ? Also, you're really using 170 different tiles ? I don't remember seeing such a diversity on maps
Quote from: Hayleia on March 14, 2013, 02:11:57 pmThe real problem was that the routine I found (don't remember where) that handles the keyboard was a pain (used groups of keys or I don't know what) That's direct input, which is fairly well explained in a lot of tutorials (for example : http://tift.tuxfamily.org/asmpourlesnuls.html ). It's not that hard to understand, the thing is that the keyboard is divided into parts, and you have to specify it to the keyboard port before reading a key state.
Quote from: Hayleia on March 14, 2013, 02:11:57 pmAww man, I just looked around in my ASM folder, reading some old code, and it brought back so many memories, when I was full of hope, thinking about coding Pokemon Topaze in ASM And I just ran that scrolling-map program again, it really works well and all I think I should try ASM again some day, I just need to find a proper routine to handle keys You still can, just to be able to play it on a TI 76.fr Also, you should try to read other's code, it helps a lot (you can look at mine, but it sure isn't as commented as it should be). And don't hesitate to ask for help here or on french forums, it's always good to help people join the restrained circle of asm z80 programmers
Yeah, it is true that I have a lot of zeroes in fact. But since no part of the map is a perfect rectangle, there would still be some waste even with divisions. And in fact, I even have tiles using numbers up to 229 Each trainer that you have to beat (those who block the road) have an associated number. This way, when you bet them, you don't have to beat them again. Maybe there is a better way to code it but for now, I have a lot of numbers
But my program only used arrow keys, which are all in the same group so it was not hard yet.
Lol, why would I play on a 76.fr when I have a 83+ and a 84+SE ?
And I am not sure that reading other's codes would help a lot seeing how hard it already was to understand and debug mine when I made it But yeah, if you know some overcommented code that I could read, that could be useful for me or others
If your maps didn't use more than 127 tiles, then you could use bit 7 to mark that it's just one tile. Normally you would do something like .db 1,tileNumber, which actually adds a byte. I do: .db tileNumber+$80, which is the same as the uncompressed size. That way your RLE-compressed maps will never be larger than the uncompressed versions.
Quote from: chickendude on March 14, 2013, 11:39:34 pmIf your maps didn't use more than 127 tiles, then you could use bit 7 to mark that it's just one tile. Normally you would do something like .db 1,tileNumber, which actually adds a byte. I do: .db tileNumber+$80, which is the same as the uncompressed size. That way your RLE-compressed maps will never be larger than the uncompressed versions.That's pretty clever ! Using the sign flag this way would definitely save a lot of bytes, thanks for the tip