Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: aeTIos on December 13, 2010, 03:28:48 am
-
Hi,
after that my calc was resetted, i decided to start again. I started up an Pokemon RPG.
Storyline:
after you have gathered all the information in your Pokedex, a guy of Team Rocket stealed it! you have to get it back, because a Pokedex is not cheap.
if you hold on, you will get it back!
Featuring all things of Pokemon games, Link cable battling(!) and more.
Screenie attached. source and compiled exec as well.
Edit: look at the post somewhere on the bottom of this page, source and compiled exec is attached there (maze demo)
-
looks good
-
This looks great! I like how the greyscale isn't very flickery. :) Great job.
How long do you think this will be? (Time wise)
-
*bump*
I think ~4 hours
-
Nice! So its really just a battle/chase game and not a full fledged Pokemon RPG?
I guess that means it'll be done sooner. :D
-
excactly! i think it will last 2-3 months (i hope less, though) to complete it
-
Interesting. I was gonna ask if you were gonna make a small version of Pokémon or an arena type game the other day since you haven't coded RPGs before but I'm glad you took the smaller route since a full Pokémon game could take a while (although feasible). Good luck!
-
thanks. btw, i really need sprites, as my spriting capabilities arent very high. i need a rocket grunt overworld sprite and a battle sprite (you are only going to fight with Rockets in trainer battles) and ~20 pokemon 16x16 sprites. oterwise, the battle engine would look very boring without sprites.
-
Please ask sprite requests in the sprite section, else they will most likely be ignored even more.
-
okay, thanks for letting me know.
btw, i'm doing a shot on spriting too
and, im going to make a maze to demonstrate the tilemapper.
-
Ah I see. Good luck!
-
I'm writing the full storyline tomorrow here. as well with some details for the gameplay. im now busy with sprites and more of that stuff. it is kinda cool, i think. done a front view pikachu sprite yet
-
Ah cool, can't wait for tomorrow then :)
-
Seems like an interesting concept. Good luck on this :)
-
okay, the time has come, i release my maze demo for demonstrating the tilemapper. no screenie else the maze will be 'unmazed'. source also attached, tile2
attachments come in a minute...
Edit:
Done.
-
It looks really good.
The only issue I'm having is that it's difficult to get around the maze for some reason--though that may be 'cause I'm playing it using Wabbit...
-
!? i thought the maze wasnt really that difficult
-
It's not that it's difficult, it's when I press the arrow keys, the little trainer person doesn't always move--even though I know for a fact that I can go in that direction, since I had just come from that direction.
-
Hmmm i didn't encounter the movement issue, and the tilemap works really well and fast :) I do have a couple suggestions tho. Maybe make your character default to the standing position whenever you are not pressing a key? Also, i have to ask, what is the ground doing? ;D
-
its the grayscale, i have to fix that, because it will get slower as the map size grows (will have to check how big the map can be without having very low speeds, tho) also, maybe the movement issue might be encountered by the (little) time that it takes to load the map, shoud fix that it loads the map every time you move and make place saving
-
Hmmm are you using Axe's default greyscale or something else?
-
yes
i use axe's default grayscale with some random pixel sprite
-
its the grayscale, i have to fix that, because it will get slower as the map size grows (will have to check how big the map can be without having very low speeds, tho) also, maybe the movement issue might be encountered by the (little) time that it takes to load the map, shoud fix that it loads the map every time you move and make place saving
Or perhaps because I'm using Wabbit? That's what I think it is.
-
maybe, wabbit is a bit slower
-
Is grayscale supposed to update like 8 frames per second? It seems like DispGraphr isn't recalled often enough. 1, you do not need a DispGraph when you use DispGraphr. Also instead of DispGraphr:Pause 150 you need to run DispGraphr through a small For loop or something. It would help a bit, although if a lot of stuff is ran afterward it might still flicker a bit.
-
okay, btw little update and speed fix: it doesnt draw the whole map so it runs at steady speed independent from how big the map is.
how did i do this:
i made 2 list pointers that give the littlest y and x value of the map, then i drew the map from {L1}to{L1}+11, (x) and from {L1+2} to {L1+8} (y)
-
Nice, you mean that it only draws the row/column of the map you are scrolling into?
-
yes, that is. i tried it with grayscale (removed it silly me) and it runs really fast :D
-
That's good to hear :)
-
Also, did you see my new userbars? (i think they're nice)
And, i started working on the Battle engine!
-
Yeah I like them actually. You should maybe put 3 to the right and 4 to the left, though.
-
yes, that would take up less space, if you meant that :P
-
Yeah I wondered because you had 6 bars to the left, but only one to the right. It would be closer to being equal with 3 to the right. :P
-
i hope its better now? i grouped the 4 bars
-
I guess that can do. I meant more like the following, though. :P
(http://userbars.removedfromgame.com/userbars.php?bg=custom&msg=Pokemon%20RPG%3A%20the%20forgotten%20quest&pct=5&lines=true&bgurl=http://img542.imageshack.us/img542/7676/ashcyndaquil.png)(http://userbars.removedfromgame.com/userbars.php?bg=custom&lines=true&bgurl=http://viathibgames.free.fr/userbar3.png)
(http://userbars.removedfromgame.com/userbars.php?bg=custom&msg=BATTLE%20ENGINE&pct=0&lines=true&bgurl=http://img222.imageshack.us/img222/2750/totodileanime.png)(http://omnimaga.org/images/userbars/84+se_sig.gif)
(http://userbars.removedfromgame.com/userbars.php?bg=custom&msg=tilemapper&pct=100&lines=true&bgurl=http://img542.imageshack.us/img542/7676/ashcyndaquil.png)(http://img259.imageshack.us/img259/561/oietwinklesj.gif)
(http://userbars.removedfromgame.com/userbars.php?bg=custom&msg=maps&pct=0&lines=true&bgurl=http://img542.imageshack.us/img542/7676/ashcyndaquil.png)
-
ah ok
ill see what i can, its kinda hard to regroup them that way :P
-
Actually now it doesn't look too bad. Fortunately, it wraps on a new line when on a lower resolution or smaller window so it should be fine. :)
-
ah ok.
Btw, minor update: added Pokecenter, Mart and tall grass sprites, now going to work on attack generation when walking in tall grass and i made the colission detection line {gdb1+.....} in r6 so its less type work to build it up
-
Cool to see more progress. :) What do you mean by attack generation when walking in tall grass, though? ???
-
omg sorry about wrong word. its an engine to generate attacks of pokemon if you walk in tall grass
i think the word i had to use is attack generator ???
EDIT:
added screenie with current progress
(i messed up filename for anti-sameattach)
in the actual game, the ground looks much better
plus i should add a clrdraw in the pokecenter textbox
EDIT2:
Added stunning pokemon sprites!
-
Those look really nice on-calc!
btw, you may want to put DiagnosticOff at the beginning of your code to remove the run indicator and "Done", and also, would it be possible to make those in 3lvl grey? :o
you want the backs of them too, right?
-
as for the grayscale, unfortunately no, i dont use pt-on for those sprites, check out the "24x24 sprites?" topic for the actual routine
for the backs: yes please!
-
omg sorry about wrong word. its an engine to generate attacks of pokemon if you walk in tall grass
i think the word i had to use is attack generator ???
I take it you mean "random enemy encounters" and/or "random battles"? This is how it is called in RPGs when you walk around then suddently everything disappears to show a battle scene.
Also the grayscale looks nicer in your screenshot, now.
-
omg sorry about wrong word. its an engine to generate attacks of pokemon if you walk in tall grass
i think the word i had to use is attack generator ???
I take it you mean "random enemy encounters" and/or "random battles"? This is how it is called in RPGs when you walk around then suddently everything disappears to show a battle scene.
I think he's talking about generating movesets for the Pokémon that are encountered.
-
Hmm I wonder how complicated that would be, especially if there are all sorts of elemental properties and criterias for each kind of Pokémon and if attack names have to be generated as well.
-
They managed to do it on the Game boy, so it should be possible.
This site (http://bulbapedia.bulbagarden.net/wiki/Pok%C3%A9mon_base_stats_data_structure_in_Generation_I) seems to have some good information on the game structure.
-
this looks rather nice.
why do you disable gray while displaying text? if you were to draw the speech window to both buffers and use dispgraphr you could keep it on all the time.
-
Actually wouldn't he only need to display it on the main buffer if he uses 3 level grayscale?
-
why do you disable gray while displaying text? if you were to draw the speech window to both buffers and use dispgraphr you could keep it on all the time.
But can you draw text to both buffers? I've looked through the Axe documentation and I didn't think text->backbuffer was implemented.
-
Yeah I'm not sure if Text can even be displayed on the backbuffer. You can always use Copy, though.
-
You can't draw text to the back-buffer, but if you draw it to the buffer, then immediately copy it to the back-buffer it'll work.
Although, if you're using 3lvl grey, you shouldn't even need to copy it the back-buffer, as anything black on the main buffer will be drawn as black if I'm not mistaken.
Edit: Here (http://www.gamefaqs.com/gameboy/367023-pokemon-red-version/faqs) is another good repository of info for Pokemon. The FAQ on the battle mechanics is tremendously helpful.
-
You can't draw text to the back-buffer, but if you draw it to the buffer, then immediately copy it to the back-buffer it'll work.
Although, if you're using 3lvl grey, you shouldn't even need to copy it the back-buffer, as anything black on the main buffer will be drawn as black if I'm not mistaken.
yeah, that is true, but I think the reason he's not using grey is because he doesn't use Pt-On to display his sprites, look in the 24x24 sprites topic for more info. ;)
-
But I thought this was about when text is displayed when you interact with something on the map...
-
Actually I'm not that sure, but last time I was chatting with him on IRC, he said something about not being able to have greyscale pokemon sprites because he doesn't use Pt-On for sprite displaying... although he could still use copy...
-
How does he draw the sprites? ???
-
I draw them this way:
[store pic info here]->pic1
0->X->Y
For(A,0,23
{A*3+Pic1}r->{A+Y*12+L6+X}r
{A*3+Pic1+2}->{A+Y*12+L6+X+2}
End
DispGraph
Repeat getKey
End
^^ instead of splitting them into 9 8*8 sprites
-
what's the advantage of doing this? (sorry, I have trouble reading other people's code. D:)
-
you dont have to split your 24*24 sprite into 9 8*8 sprites, so its less work and less time
-
I see. Was your crash related to displaying the sprites?
EDIT: WOW! I just realized, your time registered was at 00:00:00
-
Ooh I see now. Direct memory storage. Seems like a nice trick if you want to use large sprites. Is it slower or faster?
EDIT: WOW! I just realized, your time registered was at 00:00:00
O.O
-
Ooh I see now. Direct memory storage. Seems like a nice trick if you want to use large sprites. Is it slower or faster?
i think same speed
-
Ah ok, well it's good if it's not too slow. It should make using large sprites much easier if used through a Sub() routine.
-
even if he's drawing in only 3 levels of gray he would still have to clear the back buffer area underneath the text-box so as to avoid having bits of gray show through inside the box.
oh, and it would be interesting to know which of those runs more quickly. i doubt they're exactly the same speed
-
aeTIos, did you ever see the last post I made in your 24*24 sprites (http://ourl.ca/8370/154386) thread? If you're content with copying the sprite without clipping to byte boundaries on the buffer, then that's the most optimized code I could get. One code section is optimized for size, the other for speed.
-
*bump*
its still going on.... but slowly
-
Good to hear, and nice to see you back. :)