Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: meishe91 on April 03, 2010, 09:29:26 pm
-
So I was over on TIBD and was looking at their top rated games box thing on their front page and checked out Bunny Gotchi v1.7 (http://tibasicdev.wikidot.com/archives:bunny-gotchi) and it made me think of the old Digimon Virtual Pet things (and I mean the original one: little square, cracked brick looking, three bottoned one that had like 16 digi's total) and got me thinking that it'd be pretty cool to port that to TI. I was just curious if anyone else had thought of this, especially now that Axe is out there. I think it'd be pretty freaking sweet and I've thought of way to pull it off in multiple ways. I'm no where near good enough to tackle this yet (but definitely will consider this when I become better or even just start planning this out now) so I figured I would post and see if anyone might want to do it (maybe I could help? Who knows :P). Thoughts?
-
I'm in.
Tell me what to do.
-
Umm...I have no clue lol. I don't even know where to really start with this.
-
One person here had in mind to make such project and maybe even started it a while ago. However, I don't know what happened to it. It would be nice to see, though.
-
Interesting. Do you remember who it was?
-
DIGIMON!!!!!!! WOO!!!!!
I can make sprites.
-
Well I just looked up an original image and just found an Agumon sprite and put it on my calc and it looks like they are 14x15 (or 15x15 if there is a blank space at the top/bottom). I don't know how big the others are...just thought I'd throw that out there.
-
I don,t exactly remember who did it x.x sorry
-
No worries. I'm working on creating the original sprites right now...I'll post them up when I'm done.
Edit:
Ok, so I got all the basic sprites into a .bmp file. What is the easiest way to get the data from that file onto my calc? I saw in the downloads the Bitmap to z80 (http://www.omnimaga.org/index.php?action=downloads;sa=view;down=520) program but I'm not sure how to use the file/s it gives you. Help is well appreciated :)
-
Well the BMP to z80 is more for z80 assembly and Axe Parser programming, since it outputs hex data. You need something like TI-Connect or Image Studio (in our downloads section) to convert sprites to 8xi file. Also don't use row 64 and column 96 of pixels, because those softwares will erase them. TI-Connect comes with a software that opens bmp, jpg and 8xi files, and lets you convert them.
-
Ya I know that what it did, I just wasn't sure how to use the programs for that purpose though (like how to use the information it gives you to get the sprites). But I'll try TI-Connect, I didn't know it can convert .bmp files.
Edit:
Got it onto the calc :D I'll upload what I created.
-
Wow pretty nice looking :D
-
Thanks. Took forever to do because I was trying on the calc to do it but then somethings weren't looking right so I switched to Paint and did it there. That's why I was asking how to convert it.
-
Oh wow I remember doing sprites on calc. I had no regular PC access when I did ROL3 and it took me 2.5 months just do do two sprite sheets where not even all of its 12x8 rows were used
-
You could write it in 84+ Basic utilizing xLIB, that would on the one hand ensure that as much people as possible are able to contribute, and on the other hand it would expand your possibilities to a level, from which almost everything is possible.
Oh and If you need help, I could e.g. take care about the menus - I love making menus ;D
The Structure of the program could be like this:
[Launcher] (in RAM)
- copies the Sprite-Picture to Pic0 (in order to make it usable for the xLIB Sprite engine)
- sets up a list for the savegame
- contains the main menu
- copies the main subroutine (in Archive) via an xLIB-command into RAM and executes it.
[main subroutine] (in Archive, as XTEMP in RAM)
- manages the main function and calls other subroutines via xLIB-commands (if needed)
p.s.
The sprites definitely rock.
-
Ya, it can be a real hassle. Glad I remembered there were ways to do stuff on the computer :P
About how to program it, ya I haven't decided what would be best. I mean if I/we did it in BASIC just about everyone could possibly help but I don't know how the speed would be. If I/we did it in Axe I think we could open up a lot more realistic touch to it. I don't know. I'll have to think about it. (A major part that would contribute to the decision is implementing things like the feeding, pooping, cleaning, fighting, training, etc. engines and all. Moving I think should be pretty easy though.)
-
Ya, it can be a real hassle. [...]
Oh sorry, that wasn't my intention :-[...
A major part that would contribute to the decision is implementing things like the feeding, pooping, cleaning, fighting, training, etc. engines and all
*rofl*
-
Ya, it can be a real hassle. [...]
Oh sorry, that wasn't my intention :-[...
A major part that would contribute to the decision is implementing things like the feeding, pooping, cleaning, fighting, training, etc. engines and all
*rofl*
Umm...I'm sorry but I'm not sure I exactly know what you're referring to in what context.
-
Ya, it can be a real hassle. [...]
Oh sorry, that wasn't my intention :-[...
A major part that would contribute to the decision is implementing things like the feeding, pooping, cleaning, fighting, training, etc. engines and all
*rofl*
Umm...I'm sorry but I'm not sure I exactly know what you're referring to in what context.
well, dict.cc says
hassle = to pressurize
Btw Quote pyramid! ;D
-
Oh, so you're German? Sorry, when I said "hassle" I was using it in reference to making the sprites on the calc, as in it was hard (I don't know if that cleared that up). I wasn't saying it to what you said or using the definition "to pressurize." Sorry about the confusion.
And thanks for the way to possibly organize things, it could help in the future. But in regards to the menu things. It depends which way be go, but ideally there shouldn't be any if we do a port because there weren't any in the original hand-held devices. I think there would just be a splash screen and then go to the game (if any menu probably just a simple "continue/reset" one, nothing major) but thanks for the offer :)
-
Yes, I'm german, But I get your point - I just wasn't thinking about a port...
So far, so good. I'll come back tomorrow... ;)
lolje
-
Ah ok.
-
It was I who wanted to try the tamagochi... What I wanted to do was actually use the internal clock that the TI84+ has and make it so that it runs even if you are not running the program (actually, what it's supposed to do is to compare the time you last turned off the program with the time you are turning on the program, calculate what your character's stat is supposed to be (such as hunger), and update it.
Well, I never really did anything, it was just a concept.
I think this is going to be pretty cool! I love the sprites too. Btw, are you thinking about implementing link feature, to allow the digimons to fight? or even get marry ;D ? It would be epic!
-
Oh ok, that would have been cool and would be cool if I/we could implement that type of thing into this (maybe like two versions, one without clock and one with). But ya right now this is just a concept mainly but hopefully I can work on it some or something.
About linking, ya I was planning on it because that would be cool. Though I don't remember the Digimon getting married part :P
-
So I found my the Digitmon device thing that I'm trying to emulate...there are a lot of sprites that need to be created if I want it to be legit :P
-
How many approximately do you think? I wonder if it will fit on regular 83+?
-
Well...there a lot haha. I haven't been able to see each character (there are fifteen including the egg) but it looks like each one has three different basic movements while walking around (and then just the same sprites but reversed). So just by that estimate there are forty-four sprites for the walking sequence stuff alone. Then there is eating, fighting, healing, and all that stuff. Which I'm guessing there might be about two sprites per thing but I'm not sure. So in total I'm thinking there are a total of at least seventy-five sprites at the least.
So, I'm gonna probably safely assume this will best be attempted in Axe as it will mostly likely be the fastest (aside from doing it straight in ASM which I'm not really ready for that :P). I'm not even sure how to really do it in Axe but ya. We'll see what happens. Definitely going to be a feat in itself and a challenge.
One idea I had for the sprites though in Axe is that since you can offset the data (I believe? Correct me if I'm wrong.) you could put all the characters data in one place and then write the algorithms to call it back. I honestly think the sprites will be the hardest thing to do.
Please put you're input in, I would really like to hear what you guys have to think and need suggestions.
(http://fc05.deviantart.net/fs48/f/2009/193/2/0/digimon_02_by_lydia200.gif)
-
hmm... if there are 75 sprites, and about 15 can fit in one picture file, you only need 5 picture files, isn't it?
I think 5 picture files are not too bad, especially with xlib you can keep the pictures archived. Well, I think Axe also can be good too, but since I never used Axe yet (having other projects to do on the calc) I really can't tell you. Well, no matter what platform, good luck!
-
I'm not sure if Axe sprites are easier or harder, but one thing to consider is that in Axe, there are no subprogram support yet, meaning your game is limited in size, and with xLIB, the player is forced to carry a huge 16 KB APP on his calc to play the game. If the sprites are 16x16 you can fit 15 on a pic if done on the computer and 18 if on calc (most comp softwares get rid of column 95 :/). So with 75 16x16 sprites you would need 5 pics. If they're like 24x24 you can fit 8 per pic if done on calc and 6 if done on the PC. In this case it would be 10 pics if done on calc and 13 pics if sprites are done on PC.
-
Well I have absolutely no experience with either xLib (well I messed with it a long time ago but got nowhere) or Axe (but I have read the files and plan to go over peoples programs) so either way I'd be starting from scratch haha. I just figured Axe would be faster in terms of speed. I really need input from people on their opinions and such.
I'm not sure if Axe sprites are easier or harder, but one thing to consider is that in Axe, there are no subprogram support yet, meaning your game is limited in size, and with xLIB, the player is forced to carry a huge 16 KB APP on his calc to play the game. If the sprites are 16x16 you can fit 15 on a pic if done on the computer and 18 if on calc (most comp softwares get rid of column 95 :/). So with 75 16x16 sprites you would need 5 pics. If they're like 24x24 you can fit 8 per pic if done on calc and 6 if done on the PC. In this case it would be 10 pics if done on calc and 13 pics if sprites are done on PC.
That went way over my head. What do you mean by on calc and on PC exactly? And with the storing multiple pics to one picture file, didn't understand that either.
The sprites are at most 16x16 by the way.
-
on calc, I mean if you create your sprites using DRAW->Pen tool then storepic. On PC I mean if you create your sprites using Paint then convert using either Image Studio by Cullen Sauls or TI-Connect Screen Capture
-
Why does the computer limit it so much?
-
I have no clue. For some unknown reasons, when converting, Image Studio/Ti-Connect erases your column 96 x.x. Don't ask me why. I think what happened is that the authors thought that row could not be used in BASIC, even with the help of ASM, and despite the fact it can be stored in pics, they decided to strip it anyway >.>
-
What a coincidence haha, I've been going over Axe so I could make a game like this. :P
I wrote a BASIC Digimon raising game about a year ago, it wasn't graphical but it had all of the digimon from the first digivice, and more or less the same evolutionary patterns. You could feed them, clean up after them, play with them, train them, and rest them. IIRC I had some simple attack/defend battle mechanics for the fights. I was almost done except for programming the linked battles, which is where I stopped, because I then decided to rewrite it using xLib and make it graphical. I got most of the sprites into my calculator, but never really got off the ground with it, which is why I've been studying Axe recently to try it out again. :)
Anyway, there was a site I used by a guy who was pretty into the digivices, he had a lot of good information about the way they worked. Unfortunately he seems to be doing some renovating of his site and he hasn't put any info back on yet. In any case, give him a ring if you ever need to know how something worked. His site is http://www.digimonpet.co.nr/, and he's fairly active at its forums. Also, WithTheWill could provide any other information you need. Good luck!
-
Weird...do you know why that if you have pixels on the far left of the picture (like column 0) why they duplicate and shift everything over a pixel?
-
Hi and welcome here tensuke. I am curious what ideas you are coming up with. Are you pretty active into calc programming?
/me wonders if this could eventually become some sort of collab project
Meishe: are you using Celtic III by chance now? I am starting to wonder if this isn't the bug I encountered in it with real(1. In some of my xLIB games, if I run them with Celtic III, some sprites seemed off by 1 pixel. I guess if it's the same thing, it might be the occasion to report this issue to Iambian on UTI Celtic III thread
-
No, it wasn't during execution of the program. It was while transferring that sprite sheet to the calc. I had the sprites (well the ones on the left) lined up with the edge and when I transferred to calc it all shifted one pixel and duplicated those pixels. I'll try to show what I mean.
Original Image:
_____
X____
XX___
X____
_____
Transferred Image:
______
XX____
XXX___
XX____
______
^
This row was added.
If that makes sense.
And ya, I saw that page while looking for some images. I was curious why there was a lack of information.
-
Mhmm strange x.x
What is the dimension of your image file? Maybe it's being resized
-
I have also had this problem when trying to transfer images to my calc. I'm not sure what dimension will allow the image to be left alone tho, if it works at all, TiConnect might just suck :/
-
Well on that I'm pretty sure the overall image was 95x63 (0-94 and 0-62). Maybe if you change it to 96x62? Since that is what the screen really is?
-
Oh that's the problem then x.x
You need to set it 96x64.
-
Ah ok. Well in my defense I didn't know the screen was 96x64 :P Where is the 64th that isn't accessible?
-
I think it's for that (usually annoying) status bar on up right.
-
Well the 64th row would be horizontal I believe and the status bar you're referring to (I think, I could be thinking of the wrong one) is vertical.
-
Ah ok. Well in my defense I didn't know the screen was 96x64 :P Where is the 64th that isn't accessible?
It's ok, the issue is that TI decided to be stupid and now allow the usage of row 64 at the bottom. For column 96 I think the issue was the busy indicator, though, but I still wish they allowed its usage by default.
-
Well where is the 64th exactly? I've just never seen a row that wouldn't turn on I guess ???
-
Come to think of it, I haven't seen any virtual pet programs for the TI's comparable to the real virtual pets. Let me know if you need any extra help with the coding, this is a cool idea.
-
Ya, the only graphical one I saw was that Bunny Gochi one I mentioned in the first post but it is all home screen I think. Thanks for the offer :) I may have to (probably will :P) take you up on that offer sometime.
-
Well where is the 64th exactly? I've just never seen a row that wouldn't turn on I guess ???
If you look very carefully at your calc LCD, you'll notice 64 rows of pixels :P (unless you got a TI-Nspire)
-
Oh ok, I see it now :P
-
Whats weird is that under no circumstance is the 64th row used by the TiOS at all ??? Maybe they liked odd numbers :P
-
I remember in xLIB you could actually store to row 64, though, in later versions. It made a pic of 779 bytes instead of 767. You had to store your sprites in another pic, overwrite LCD with the spritesheet you want them on, then display on row 8 of it, and store with real(9 command. Do not store with Storepic nor open-save your file in another image editor cuz then the row may get erased.
-
Whats weird is that under no circumstance is the 64th row used by the TiOS at all ??? Maybe they liked odd numbers :P
Ya, I've never seen it used anywhere :P One of us should get a job at TI as a programmer and make everything so we are able to use it better :P
-
It only uses 63 rows so they can place the x axis on the center pixel row.
-
I'm going to assume they just tossed the run indicator in for that purpose too, so they had an excuse to not leave to rows unusable.
-
the run indicator isn't tossed in, it has a very important purpose, but graphing only uses 95 pixels instead of 96 for that reason also.
-
Is the important purpose to show that the program is running? Because depending on the case it isn't that necessary and looks bad if you're going for a professional look. But anywho.
-
Always remember that in ASM you can use all 96x64, though. Even using xLIB you can, except the run indicator, unless disabled, will show over the stuff at the top right.
For BASIC there are various tools to disable the run indicator, except if you use archive/unarchive commands, it's enabled back.
-
The run indicator indicates the current state, it tells you that it hasn't crashed. It's pretty important even though it looks unprofessional in games.
-
the thing, though, in BASIC, is that it's supposed to be impossible to crash a game. I assume it could be useful to make it easier to know if a program exited prematurely or is in paused mode, though.
-
the runindicator runs in asm and apps too if it's not disabled and im1 is on
-
Yeah I know. I personally rather prefer to disable it as soon as my game development is done so it looks more professional. Also on a side note, don't worry about the run indic overwriting the pixels in the first pixels of the 96th column, the last thing I noticed is that it appears to leave everything under it intact, so no display glitches should occur if you display stuff there without turning it off.
-
Ya, I know it can be useful to make sure a game hasn't crashed and such. I just meant that you should maybe have the choice of having it or not (maybe for like testing speed or something). I do think it is important when it comes to pauses though because you can't tell otherwise (unless told you're paused :P). Didn't mean it to sound like it was useless (when I said it was just tossed in there I was kidding because I know in games it's usually disabled by some means) I just meant that you should have the choice or something of having it or not. Sorry.
-
as I said, though, it can be easily disabled through the use of ASM libs. Axe even has a command to turn it OFF, if you check the doc. It's DiagnosticOff/On
-
Oh, ya, I know. I was just referring back to when I was talking about how one of us should go infiltrate TI as an employee and help program the OS's for our benefit :P Thanks for telling us though :)
-
Haha, that reminds me... didn't somebody on MaxCoderz or UTI actually went doing that (or at least get in TI headquarters) a few years ago? He even posted some pics. I think it was Digitan000 but I'm not sure anymore.
-
That is pretty epic :P What was he doing there?
-
I don't remember anymore. I think he was just curious and decided to be a rebel and go in areas he's not allowed in :P
-
Very rebel like :P Wish I could do that. Would need to know where exactly all that stuff goes happens though lol.