Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: DJ Omnimaga on May 06, 2013, 05:35:17 pm
-
Ok so when I released that one other crappy Zelda game that looks like Atari 2600 material, my intention was to see how fast TI-84 Plus C Silver Edition BASIC drawing was in games of my own, but I wouldn't stop there. I had plans, once I finish that game, to go a little bit further, first of all with better graphics and secondly with actual Zelda gameplay rather than just finding keys and avoiding enemies. Currently, this project is mainly in experimental and planning stages, but should it go further, it could possibly be the first Zelda clone to arrive on the TI-84+CSE color screen calc.
The game would be written in TI-BASIC, with the help of LCDTOOL ASM lib so that the game can run in 160x240 resolution. The game style would be similar to the original NES Zelda from 1986, especially dungeon map layout, but with lower quality graphics, for speed reasons. In some cases, the game might still look Atari 2600-like, but far better than in Sord of Atari. Coding might still be sloppy, though, because it has been over 3 years since I last touched TI-BASIC.
Currently, ideas for items were found, but the blue and red tunics are not guaranteed to remain in. Also, I am still unsure if I'll use the heart pieces format or full hearts yet. I also have ideas for the types of dungeon/overworld rooms.
All that is implemented so far is initial map loading (without the doors, floor content, items, etc) and link's movement (he faces 4 directions) with no collision detection, map/sprite interaction, with bombs/equiped items/keys still missing from HUD. I also have an experimental boss 1 program which doesn't do anything else than displaying the boss then moving it around. Bosses will most likely use their own map/movement engine to avoid losing speed in the main engine and it is possible that multiple bosses' behavior will be identical, to save RAM. The title screen is also done, including a spinning triforce. The Zelda logo is generated using stat plots. I also have the map data for the overworld done, but I need to convert it to a different format, so hopefully it should make things easier to test.
The reason why I want to use the NES dungeon layout is to save size/speed. With the way maps are layed out in my engine, when you switch from one room to another, only the doors/pathways and the floor sprites have to be erased, then the next map sprites are loaded. THe only time the entire map (and menu) would have to be reloaded while in-game is when exiting or entering the dungeon, since the color palette or floor texture can be different.
Anyway, will this be another project that will die? Will it go further than an engine? Or will it eventually be the 2nd real calculator Zelda project ever completed since 1985? Hopefully it is the latter. For now, I'm leaving you with screenshots, which runs roughly at the same speed as the calc (walking is about 10% slower on calc, but it flickers much less).
-
So the calc RPG legend is back with a new RPG project it seems.
Nice, can't wait to see how nice games on the CSE would be.
-
Finally getting back into some programming, eh? I'd like to see what this turns into later.
-
Awesome initial screenies!
/me wants a CSE now.
-
I agree with pimath, I haven't really thought much about getting a CSE but I am starting to want one. Great job and keep with it!
-
you are actually programming again? O.O
Nice, and I hope you'll be able to finish that project :D
-
Wait what !!! DJ is going back into programming?
-
Nice to see you picked programming back up. ;)
And yeah same as Pimath and Zeldaking, I was waiting to see what the community would come up with before I get a CSE, and since it looks like we already know a lot about it, I'll probably get one. I hope the speed is not an issue though.
-
Good luck with this. Looks pretty nice already.
-
Thanks guys. :) As for speed in this game I guess we'll see, but I don't think it should be that bad if I keep all events outside the main loop. As for the calc in general it depends what you do, but it seems that so far it isn't as bad for certain tasks like we thought before.
-
It's great to see you coding again DJ_O! I look forward to seeing the development of this project
-
Great ! Can't wait to see finally a true game on this calc :D
Not that I don't like Sord of Atari but this one looks better :P
Good luck with it, and if you need beta testers, I may not have a lot of time to do bug hunting (like bumping each wall to see if one in particular doesn't support collisions) but I still can test quickly if the overall thing works :)
-
(like bumping each wall to see if one in particular doesn't support collisions)
I 120'd at that one.
But yeah I'm looking forward to progress on this. I wish there were a BootFree-like thing for the CSE so I can check this out before I eventually get my hands on one. ;)
-
(like bumping each wall to see if one in particular doesn't support collisions)
I 120'd at that one.
What does "120" mean ?
Also, maybe you are wondering why it is needed to bump each wall, but there are some strange particular bugs in Pokemon Topaze:
-One trainer in the last Gym teleports you out of the Gym when you beat him. Other trainers don't teleport you.
-One tile in the last cave (iirc) teleports you if you encouter and beat a Pokemon on it. Other tiles don't teleport you (proof in attachement, it is an old version of Pokemon Topaze, where Pokemons were not drawn in battle).
I never found where those bugs came from :P
If you have spare time, I encourage you to try those bugs, they are completely harmless and pretty fun to see ^^
-
What does "120" mean ?
Well, in 1337, LOL becomes 101 which is 5 in binary. Hence LOL! is 5! which is equal to 120. :P
-
What does "120" mean ?
Well, in 1337, LOL becomes 101 which is 5 in binary. Hence LOL! is 5! which is equal to 120. :P
Ok, 39 for the explanation :p
Seems like you like putting numbers instead of words so I put 39 to mean "thank you" because in Japanese 3 is san and 9 is kyu so it gives "san kyu" ;)
-
What does "120" mean ?
Well, in 1337, LOL becomes 101 which is 5 in binary. Hence LOL! is 5! which is equal to 120. :P
Ok, 39 for the explanation :p
Seems like you like putting numbers instead of words so I put 39 to mean "thank you" because in Japanese 3 is san and 9 is kyu so it gives "san kyu" ;)
I don't do that for anything else than LOL. ??? I just saw it on urban dictionary and found it kinda fun. :P And yours is nice too. ;)
-
120d has been a running gag for a while on Ticalc.org back then too. People kept saying that instead of lol. Then later on Cemetech lol got censored to 0x5.
Anyway not much progress on code since I was kinda injured early in the weekend then got busy shopping for games, but I was debatting about if instead of texturing the floor I should texture the walls and ceiling instead. Due to the way the sand/grass-type floor is drawn, it would be hard to redraw it after using the sword, since it isn't tiled. That isn't a big problem for the rectangle tiling texture, though.
Also note about the Boss sprite on page 1: The reason why it's so fast when moving it around despite being so large is because to move around, the left side is erased and an extra row of 3x3 squares is displayed on the right side, or vice-versa. The middle of the sprite is never refreshed. The only downside of this technique is that the sprite can only move left-right, not up-down.
-
120d has been a running gag for a while on Ticalc.org back then too. People kept saying that instead of lol. Then later on Cemetech lol got censored to 0x5.
Anyway not much progress on code since I was kinda injured early in the weekend then got busy shopping for games, but I was debatting about if instead of texturing the floor I should texture the walls and ceiling instead. Due to the way the sand/grass-type floor is drawn, it would be hard to redraw it after using the sword, since it isn't tiled. That isn't a big problem for the rectangle tiling texture, though.
Also note about the Boss sprite on page 1: The reason why it's so fast when moving it around despite being so large is because to move around, the left side is erased and an extra row of 3x3 squares is displayed on the right side, or vice-versa. The middle of the sprite is never refreshed. The only downside of this technique is that the sprite can only move left-right, not up-down.
Fortunately, you could code this way for left-right movement and the ordinary way for up-down movement (if it's fast enough).
-
Did you say that you had a lib or you needed one?
-
120d has been a running gag for a while on Ticalc.org back then too. People kept saying that instead of lol. Then later on Cemetech lol got censored to 0x5.
Anyway not much progress on code since I was kinda injured early in the weekend then got busy shopping for games, but I was debatting about if instead of texturing the floor I should texture the walls and ceiling instead. Due to the way the sand/grass-type floor is drawn, it would be hard to redraw it after using the sword, since it isn't tiled. That isn't a big problem for the rectangle tiling texture, though.
Also note about the Boss sprite on page 1: The reason why it's so fast when moving it around despite being so large is because to move around, the left side is erased and an extra row of 3x3 squares is displayed on the right side, or vice-versa. The middle of the sprite is never refreshed. The only downside of this technique is that the sprite can only move left-right, not up-down.
Fortunately, you could code this way for left-right movement and the ordinary way for up-down movement (if it's fast enough).
Up/down would be possible actually, but the sprite colors would be vertical lines instead of horizontal. If I wanted 4-directional movement to be possible, the sprite would only have 1 color.Did you say that you had a lib or you needed one?
Calc84maniac sent me a lib a while ago. I asked for one for a while but eventually he made one. Unfortunately it doesn't work in jsTIfied, though.
-
Does the lib enable 160x240 mode or does it do sprites too?
-
Just 160x240 mode and/or scrolling (for now, anyway)
-
The following are just mockups, nothing implemented as is in the game, but I was wondering if you would prefer the smaller hearts to the bigger ones or vice-versa? The issue with large hearts (which use 5 pt-on commands) is that they take so much space in the HUD that even with 9 hearts, everything else is squeezed into a small space, and there is the possibility of a key glitch happening with the large hearts setup (if you decided somehow to grab several dungeon keys at multiple places, but not use them immediately, so you ended up with more than 9 keys). However, would the small hearts just be too small?
Also, below the two images I am talking about, I have attached a picture of what the menu will look like when it's full. At first it was going to be white because there was text right next to items, but that isn't the case anymore. For the item color codes, cyan and green refers to 2nd and ALPHA key colors on the calc, while gray is for support items that aren't assigned to a key. To avoid confusion, I added a colored legend in there. It is possible that dungeon keys will be removed, replaced with standard keys. Of course doing so would cause you to get caught off guard by boss encounters, but I could simply make the dungeons layout so that the official dungeon treasure is located right before the boss room or make the door colored.
Also, it is possible that there might be a map for each dungeon, but that would depend of space. It shouldn't be too hard to create, though, but it would require redrawing a part of the screen afterward.
-
I love that menu :D
As for the hearts, I prefer the small ones because they don't seem to take all the HUD :P
Also, as you said, since the big ones take all the space they might cause problems that would not appear with small ones :)
-
The only other issue though is that the text is so big compared to small hearts, lol. :P
-
The only other issue though is that the text is so big compared to small hearts, lol. :P
Yeah, true, but there is nothing you can do about the size of the text (I guess) so to have everything fit in the screen the only thing you can change is the size of the rest, including hearts :)
Maybe you should set a poll so that you have more opinions than mine ? :P
Also, what are those numbers representing ? I think the second one is the number of keys you have but I don't get the other ones.
-
One of them is rupees and the other are bombs.
-
Ok.
In fact, I was thinking that if one of those numbers was not "useful to the action", you could put it elsewhere. For example, you don't really need to know how many rupees you have when you are in the middle of a dungeon, but you constantly need to know how many bombs and keys you have, so the number of rupees could be put in the menu for example (if you compress things a bit in the menu :P)
-
I think I'd go with the smaller hearts. :)
-
Ok.
In fact, I was thinking that if one of those numbers was not "useful to the action", you could put it elsewhere. For example, you don't really need to know how many rupees you have when you are in the middle of a dungeon, but you constantly need to know how many bombs and keys you have, so the number of rupees could be put in the menu for example (if you compress things a bit in the menu :P)
To be honest i don't really like how this looks like with the large gap at the top. Plus in all Zelda games you see your money in the main HUD, so removing it would be kinda inconsistent. What could possibly be done, though, is removing the total keys althogether and move it to the menu somewhere, such as above orbs but inside an area with white background, but not at the top .
-
Here is another idea I had. Those hearts don't seem to look as nice, but hey, what can you do in 3 pixels width resolution? :P (which is actually stretched to 6) Basically you would have 16 hearts max plus 16 magic points.
I also included the menu without the boss keys. As for regular keys I tried putting them inside the menu and it just didn't look good anywhere, so I think I'll just make sure that while the game isn't too linear that it's still impossible to stack more than 9 keys at once or I'll go the cheap route that is 10fpart(.1K) (basically when keys reaches 10, it looks like it loops back to 0, but in fact you really have 10 keys) :P
-
Sadly not much progress due to being busy, sleepy (especially since the last month or so) and doing other things, although I recently experimented with more advanced wall graphics for the overworld. However, I'm not sure if I'll use them because the program that generates them is 800 bytes large.
Regardless of if I use it or not, however, I might need help optimizing, because before the 84+CSE was announced last Winter, I didn't use TI-BASIC for 3 years, plus I am mostly familiar with tricks from 1999 to 2003 or so. The main issue right now is that I have to use a crapload of Line()/Pt-On commands, with some For loops, but when I'll have to code map generation further to check for doors, items, etc, I worry that my code will turn into a big cluster of if/then/else spaghetti code.
Anyway, here is the new overworld dungeon layout idea I had, with walls inspired from Link's Awakening (slightly less complex in order to fit the half horizontal resolution and to save RAM):
(http://illusiat.reubenquest.net/xlib.mtv-music-generator.com_imagesThatWereOn57o9WhereJujuShouldPointTheXlibMTVMGSubdomainToBeforeWeLoseTheGame/zeldalastyle.gif)
It actually checks if the next maps are linked to the current one to open pathways, but only horizontally. What will make map checking file size skyrocket is the fact that there are 4 ways to check and I'm unsure about how to do it efficiently when there are like 9 different types of entrances/exits (meaning 36 potential If blocks)
-
Lookin' pretty awesome DJ !
-
Indeed, that is great :D
However, as you said, this is pretty slow to draw :P
Couldn't you draw the "walls pattern" once for all at the beginning of the program, StorePic it then when entering a room, you just RecallPic it then put the holes where the doors should be ? That could be an interesting gain speed imo ;)
-
^That.
-
I don't feel it's actually that slow, although it's slower than the other dungeon walls and slower to switch between rooms (although a temporary picture can come to the rescue for such thing). I was actually surprised at how fast I can draw graphics this complex, considering the walls are from a game boy game.
However I won't use one pic per possible room layout (for example with blocks, rocks, doors, etc), else the game will require 3 MB of archive to run O.O (22 KB per pic). What happens is when reloading a game or entering a dungeon, the walls are drawn, then whenever I need to draw a door or path, I simply erase parts of the wall, then when Link goes to another room, only those parts are refreshed rather than every wall as a whole. Using one pic would be nice, even if it costs 22 KB of archive per pic, because I would just recall the pic then redraw new doors/paths. The problem though is if I use a pic, I would have to redraw the menu everytime I switch to another dungeon, since I can't store it into the pic (else redrawing the dungeon walls would screw up the menu)
-
Using one pic would be nice, even if it costs 22 KB of archive per pic, because I would just recall the pic then redraw new doors/paths. The problem though is if I use a pic, I would have to redraw the menu everytime I switch to another dungeon, since I can't store it into the pic (else redrawing the dungeon walls would screw up the menu)
Why can't you include the menu in the pic ? Isn't it on the right part of the pic ? Can't you draw the walls and the "sprites of the menu" (if you know what I mean) on the pic, then when acessing the menu you just have to add the text ?
-
Because if during the game, for example, I acquire a new item, lose HP (or regain some), get rupees, use bombs, recalling a picture will revert back those HUD/menu changes to when I entered the dungeon. The best scenario would be to draw the entire dungeon and menu borders then store the picture before displaying the rest, so that whenever I recall the pic, those parts aren't overwritten. Of course using such technique means I cannot use ClrDraw, though, but I could possibly do the dungeon layout in a way so that I don't ever need to ClrDraw.
On the TI-84+CSE, white doesn't act as transparent like on Z80 calcs, btw. If for example you use a yellow background then draw one horizontal line of the same color on top of it, even though the colors are the same, the line will be the only part that isn't transparent (pixels are turned ON)
-
Looking through the new topics posted in Calc Projects/Ideas, I was really surprised/happy to see one that was started by you. Glad you're getting back to game programming!
I don't anything about the CSEs in terms of speed (hoping to get one soon), but drawing doesn't look too slow to me when compared to other (non-color) TI-BASIC games. Graphics are looking great!
-
Thanks :D. Now if only I can do more progress on this soon. At least vacations are coming (and I have two more vacation weeks after the summer fest).
And yeah drawing isn't too bad. What is bad is updating the entire screen at once, though, so one could not, for example, create an epileptic animation with For(Z,0,99:DispGraph:Disp:End like we could do on older models, plus pics are really large (although they take no RAM).
If this game uses temporary pics it will probably use hacked pics rather than the 10 standard ones, since Devpic still works fine on the 84+CSE (it lets you use 30 extra pic tokens). I need to check if such program transfer fine from a calc to another, though. That would prevent pics from overwriting people's pics, which is a reason why some people dislike basic programs.
-
I was thinking about making custom PIC's as appvars that could be given a custom name by the user to prevent the overwriting issue.
-
That would be nice actually, although while at it, the size issue should probably be solved, since pics are already really huge D:
-
Well in tests ive used PIC's that are 256 colour (a standardised palette) with a res of 152x104 (15808 bytes), but scaled by 2x so they are 304x208. Its enough to store 247 8x8 tiles.
-
That is quite nice. How large are the pics?
-
They take up 15808 bytes.
-
Maybe you could even add some compression. ;)
-
it's funny IMO how much bigger the pics on the CSE are due to the color, and on the other z80s we talk about 787 bytes....
but yeah, compression would be awesome and since de-compressing doesn't use the screen it should be quick, right?
-
it's funny IMO how much bigger the pics on the CSE are due to the color, and on the other z80s we talk about 787 bytes....
16 KB would be most of the memory on a TI-83/84 Plus haha
The majority of whole calculator programs are smaller than that. And yet 16 KB is nothing in terms of a full computer... There's quite a difference in scale here, amazing to think about.
-
Well, the CSE also has 12.5 times as many pixels (full screen that is), so that makes a huge difference.
-
Maybe a smaller PIC size would be more beneficial. Of course regardless of the PIC size, any lib will most likely read them from FLASH anyway. On calc compression is a possibility but would be a performance hit.
-
What about RLE compression? I wonder if it would be small enough if the sprites aren't very complex? That said, the archive is higher so I guess it's not much of a problem. Maybe add a 16 color mode (where the user can supply a palette prior displaying a tilemap or just use the default TI-BASIC colors) like on the NES for people who want to save space by using fewer colors.
-
I wonder why the calculator doesn't natively use some simple form of compression, seeing how 16 KB is such a big chunk.
-
It'd be best to have a tool to decompress on calc, the compression should be done PC side.
-
I wonder why the calculator doesn't natively use some simple form of compression, seeing how 16 KB is such a big chunk.
Indeed. After all, the PRIZM does (at least, that's what I could see, from the varying pic size).