Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: Sorunome on October 01, 2011, 01:27:02 pm
-
Hi there, some of you may have noticed back on cemetech, that I started to program a roll-playing game in axe with 3-shades of grey. Here's a screenshot:
(http://i.imgur.com/QhuNp.gif)
-
That looks great! The graphics are very smooth and look great together.
Are you going to implement scrolling? And is there a storyline for this?
-
Sorry, what do you mean with scrolling? And I will make a storieline! :)
-
scrolling. like the sprite stays in the center of the screen, but the field of view moves with you.
-
Oh no, the movement stays like it is.
-
would you mind hosting the screenshot on removedfromgame.com? imgur is blocked here.
-
No, not at all. :) Here you go:
(http://img.removedfromgame.com/imgs/screenshot1.gif)
-
This looks awesome, Sorunome. It's nice to have another Axe RPG in the works. :D
-
Thanks! I actually started on with this project in BASIC which can be read here (http://www.cemetech.net/forum/viewtopic.php?t=6399&start=0) but it was to slow and I found out that there is something better as Axe in the world so I re-programmed it. But I have now already more done than in the BASIC version. :)
-
This looks very nice. Although I never really completed a rpg, I'd love to play this one.
-
That looks wonderful.
Do you have any ideas on a story line yet?
-
Thanks for your comments! Well, I have already a intro, but I don't have to worry about the soty-line since my bro does that part. I just do the programming! :)
-
Hey, it looks great. Good luck!
-
^Thank buttsfredkin^
Anyway, BIG UPDATE! I know, that I said that I wouldn't make the map scrolling, but I decided now different. I finished that, you can go into houses and you can read signs. I also started with the stats bar at the bottom of the screen. Check out the screenshot!
(http://i.imgur.com/WX6gy.gif)
-
Looks very nice. :D
-
Will you implement smoothscrolling?
-
Are you going to implement scrolling?
Oh no, the movement stays like it is.
So I think smoothscrolling will not be implemented ;)
-
Are you going to implement scrolling?
Oh no, the movement stays like it is.
So I think smoothscrolling will not be implemented ;)
Well, that scrolling is already very smooth, you have to remember, that the character always jumps 8px and scrolling is also 8px.
-
I remember seeing this on Cemetech before but I didn't have enough time to check all projects anymore. This looks nice and I'm glad your tilemaps aren't completely flat, like in Dragon Warrior (where houses are just a bunch of blocks instead of more 3D-ish looking buildings like in your game).
I hope to see progress again soon!
-
Well, thanks! But remember: I didn't make all the sprites, Ashbad made some e.g. the houses :)
I'm currently working on letting enemies displayed correctly, but it doesn't seem to work correctly.... :(
-
I got a little problem: As the map differs from quest to quest a bit I wanted to manipulate the map-data. It is stored in K as hexadecimal.
To manipulate I have now following code:
:Copy(K,L1,714
:33->{L1+20
:CopyL1,K,714It doesn't change the map at all. Could someone please help me?
-
Why don't you just say 33->{K+20} ?
-
That doesn't work either. :(
-
Nice screenshot!
-
Try 51->{K+20} so that the hex 33 is converted into decimal.
I don't know if that would work either, but why not try ? ;)
-
the problem is: it doesn't change anything at all... :(
-
Can you give us the line where the K first appears (and if it is GDB1→K, where the GDB1 first appears) ?
-
:[0101010101010101010110101010101010101010101010101010101010101010101101010101010101→K
That is the first line of the map where you start, K is redefined when you enter a new map
-
K is redefined when you enter a new map
You mean that you have
:[0101010101010101010110101010101010101010101010101010101010101010101101010101010101→K
:...random code...
:[0202020202020202020220202020202020202020202020202020202020202020202202020202020202→K
somewhere ?
-
yeah, exactly
But now I want to change in the big map just one tile or so and so i want a shorter code for that than re-typing the hole map.
-
Try to replace
:...random code...
:[0101010101010101010110101010101010101010101010101010101010101010101101010101010101→K
:...random code...
:[0202020202020202020220202020202020202020202020202020202020202020202202020202020202→K
with
:[0101010101010101010110101010101010101010101010101010101010101010101101010101010101→GDB1
:[0202020202020202020220202020202020202020202020202020202020202020202202020202020202→GDB2
:...random code...
:GDB1→K
:...random code...
:GDB2→K
I recommend to backup before (in case that doesn't arrange anything) if you want to try.
edit: I added colors so you see what replaces what, and what is added
-
But that wouldn't prevent that I have to re-type the hole map instead of just changing one byte in ram.
-
No, the problem (I think) is that you can't (I think) do
[...]→K
[...]→K
I know you can't do
[...]→GDB1
[...]→GDB1
But with K, I don't know. So I thought your problem could come from that.
And with my "solution", once you made the GDB2→K, it is the same as having done
:[0202020202020202020220202020202020202020202020202020202020202020202202020202020202→K
And then you can do 51→{K+20}
-
I don't really get what you mean....sorry :/
-
:P too much "I think"s ?
You can't do
[hex]→GDB1
[hex]→GDB1
Now the question is, can you do
[hex]→K
[hex]→K
Because this is exactly what you do.
So if you can't, I proposed
[hex]→GDB1
[hex]→GDB2
...
GDB1→K
...
GDB2→K
-
and then I change GDB1 etc. ? I'll try that, but I can't until tomorrow, still have a lot of other stuff to do :/
EDIT: WHait a sec, that wouldn't do it as I sometimes still need the original map........ I think I really don't understand what you mean, sorry. If you gave me your email I could send you all the files and you could try it out. :D
-
GDB1 is a static pointer (a value that can't change)
K is a variable (a value that can change)
Now the problem is that hex data must be stored to a pointer. I even want to say "stored at a pointer" so we understand more that the pointer becomes untouchable (not modifiable). This is why you can't store data at a pointer then store data again at the same pointer. You can't do
[11]->GDB1
[22]->GDB1
But in your prog, what you do is not storing twice at a pointer but storing twice at a variable, and I don't know if that is doable. This is why I proposed to store the first data at GDB1 and the second one at GDB2. And when you need the first one, you do GDB1->K . And when you need the second one, you do GDB2->K.
and then you can do 51->{K+20} ;)
EDIT: Wait a sec, that wouldn't do it as I sometimes still need the original map
??? So every change must be undoable ?
-
This looks great!
The reason your original code didn't work is because you compiled it to an app. This means that all data in your program is read-only since the program is put in flash rom. Now that said, you can still keep your program as an app, but you have to manipulate your levels in ram.
You were on the right track before when you did "Copy(K,L1,714)" to put the level data in ram then make changes like "5->{L1+20}" for instance. The last statement where you copy it back to rom is not going to work though. Instead, use "L1" as the pointer when you render the graphics instead of K since L1 holds the correct data with the correct modifications. If you need L1 for other things though or you need more space than L1 can possibly provide, you can create an appvar in ram any size you want and use that pointer instead.
What Hayleia is talking about is that its generally a good idea to store data to static pointers instead of variables because the code optimizes better and uses less memory.
Also I saw on your Cemetech post that you had Dispgraphr in a loop with getkey. If you want a better quality grayscale, you should not use the super slow "getkey" command. Also you should turn interrupts off. Using the direct getkey(#) is recommended instead. This gives you consistant timing between frames. You might even need to add some more pause back in. I know on hardware the 4 level grayscale is almost completely out of sync if constantly updating unless a small pause is added.
-
Ok, thanks for your help,
so if I understood it correctly greyscale works out better if I put a pause in?
-
a correctly timed pause. See, the actual lcd refreshes at 60 FPS, so you want to match that. Any faster and you miss some frames being shown, any slower and you show the same frame twice, both of which cause flickering.
Also, the front sprite looks exactly like the one from the tilemap example in BBC Basic. Is that where you got it? I could see it ending up looking the same by coincidence, though, since it's only 8x8. :P
-
Yeah, thats where i got it, but i still have to make one facing the otjer direcions than down :P
-
bump.
I randomly saw this topic in the board, and it looks awesome! Any progress/plans on finishing it?
-
No, sorry, it's dead. If you'd like to continue I could send you the files :D