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.

Of course it is better than nothing, but I still found strange to give a z80 with no Flash to someone who already owns a z80 with Flash (an Axe coder usually have a z80 with Flash ). It will just be for collection but most likely unused

The choice was made by TSP promotion, and come on, I'm sure it can still be useful to anyone in your entourage :p

Do you really think I don't push everyone I know to get at least a 83+ ?
But yeah, if the sponsor made the choice themselves, I understand they choose the cheapest calc they had in stores

I only had one use for it when it still had batteries: give games to people with 82 Stats.fr and no SilverLink in my class. But, I mean, why didn't they buy at least a 83+ ?

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+.

Tell me when you manage to fit Pokemon Topaze on a 82 Stats.fr
It is a shame that they have so few memory and all RAM, everything goes away in one RAM Clear.
At least, TI-Connect doesn't need a lot of time to check everything on the calc. It takes ages to refresh the list on a 84+SE but it is quasi instantaneous on my 76.fr

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).

Nope, It has too much data -.-°
Even the map itself already takes more than 10 000 bytes.

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...)

This artwork is really great
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

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).

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 pm

Nope, 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).

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 ?

Quote from: Hayleia on March 14, 2013, 01:11:40 pm

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

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.

Well I found a routine somwhere to draw sprites, and I managed to get a tilemapper with it (scrolling map, not smooth). But I mainly ran into two problems:
The multiplication routine I created only handled 8-bit numbers as entries. That is not a big deal, I could have changed it to use 16-bit numbers. 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)

edit 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 pm

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 ?

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

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

Quote from: Hayleia on March 14, 2013, 02:11:57 pm

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)

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.

Yeah, it was well explained in the tuto I read, so I managed to get the movement with arrow keys. But my program only used arrow keys, which are all in the same group so it was not hard yet. But I knew that going further into programming would have brought some more difficulties, of course not unbeatable but still

Quote from: Hayleia on March 14, 2013, 02:11:57 pm

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

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

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
And yeah, if I ever try again, I won't forget to ask for help whenever I need it

Speaking of which, when does the z80 assembly portion start?

Btw, with RLE it doesn't matter how many tiles you use, what's more important is the repetition of those tiles. Even if you have hundreds of tiles, there are likely places where you use one tile maybe ten or fifteen times (or more). In some of my maps, 3700 byte maps were compressed into just over 1000 bytes. So 29000 bytes of map data were compressed into just over 10000 bytes. If there's lots of repetition in your maps, RLE can be very effective. You can also play around with vertical RLE and horizontal RLE to see which way your maps compress best. For example, a map like this:
.db 1,1,1,1,1
.db 0,0,0,0,0
.db 1,1,1,1,1
.db 0,0,0,0,0
would have horrible vertical compression but decent horizontal compression, whereas a map like this:
.db 1,0,1,0,1
.db 1,0,1,0,1
.db 1,0,1,0,1
.db 1,0,1,0,1
would compress really well vertically but not horizontally. 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.

Also, for a game with very well-documented code, check out Robot War: Project Darkstar. I've also got lots of little code/programs i've written that are commented that i'd be more than happy to share/discuss with you or anyone.

Quote from: chickendude on March 14, 2013, 11:39:34 pm

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.

That's pretty clever ! Using the sign flag this way would definitely save a lot of bytes, thanks for the tip

Indeed, that is a very smart way of saving space
However, that won't apply for my map since I use more than 127 tiles
Or I could use a special treatment for tiles above 127 since those are quite rare.

Also, I just remember a reason that made me use no compression for my map: I can keep it always archived and still read it.