Ok, I am out because I can't program on that platform
The Desolate rewrite is 8lvl grayscale and runs at the same speed as 4lvl lol, but the data requirements for that would be outside the scope of this project. I think you guys need to lock down what kind of game this will be before deciding, like turn based or action game etc.I once also found a chips challenge clone and it was 8 level greyscale
Because they contain fast routines so you don't have to write you own (most of the time slower) ones, for in example accessing archive etclol, that was a retorical question stating that we could use axioms then for such stuff
I think we should keep it at 6MHz for the main engine and routines so that it stays nicely compatible with the 83+^This :D
ETAOINSHRDLCUMFGYPBVKWXJQZ,?!.0123456789/-:'
Note that the first character is a space. Now, in the actual message, any time one of the first 14 characters appear, it will be assigned a nibble 0~D. If anything after that is used, (say the 23 character in the list), it will be a two-nibble value, starting with E or F. You can subtract 14 and add $E0 to it (essentially, add $D2 to the original value). In this way, text will take at the worst 100% the original size and at the best 50%. However, because the first 14 characters are the most common to appear in an English message, it averages around 60% compression. For example, here is the message, "HELLO!" (this works best with larger messages):Xeda is the only one who actually coded something for this already
That's one fancy Lazor! O.OXeda is the only one who actually coded something for this already
Hey, I already coded some things too. Animations for a heavy laser attack :
(http://mattias.refeyton.fr/espace-ti/lasertest.gif)
(http://mattias.refeyton.fr/espace-ti/lasertest2.gif)
I'm not bad with code-based animations (I think).
Xeda is the only one who actually coded something for this already
Hey, I already coded some things too. Animations for a heavy laser attack :
(http://mattias.refeyton.fr/espace-ti/lasertest.gif)
(http://mattias.refeyton.fr/espace-ti/lasertest2.gif)
I'm not bad with code-based animations (I think).
Tileset:
; .db Evolvesto ;This is the tile it turns into on the next frame
; .db TileInfo ;a bit here will indicate that the tile needs to be updated this frame. I am sure other info
; .dw ;TilePointer ;This points to the sprite data
will be needed.
Then, a copy of the current map (I called it MapShadow), will be scanned every time through the loop. Each byte will point to a tile in the tileset, the byte will be replaced by the byte it evolves into (I'm thinking in terms of cellular automata) and if a specific bit is set in the TileInfo field, the LCD will be updated using the data and TilePointer.+ collision detection is way easier and smaller... :DYes, this is definitely the next important thing that will need to be figured out after the map engine is made. In my experience, it is always easiest to have walkable tiles as the first tiles in the set.
So I think the movement will be like this? ok lol :p
And then all walkable tiles before non-walkable this and collision detection is based on if the number-of-map-tile your standing on, is smaller then the number-of-first-non-walkable tile...?
And i sugest tiles as following: sand, dirt, stone, grass, and some other .. all to walk on, and some fences as non walk-able and some other...
:.AXESMTH
:[3C4281818181423C→Pic1TILE
:[3C7EFFFFFFFF7E3C
:[0000000000000000
:
:Buff(384)→GDB1MAP // this does take a lot of the 963b of the prgm
:0→H→V→S-1
:For(384)
:+1→r1
:rand^3→{r1+GDB1MAP
:r1
:End
:
:While 1
:‾1
:For(10)
:+1→r2
:‾1
:For(14)
:Pt-On(+1→r1-1*8-(H and 7),r2-1*8-(V and 7),{VAsm(CB2DCB2DCB2D)+r2*8*3+r1+(HAsm(CB2DCB2DCB2D))+GDB1MAP}*8+Pic1TILE
:r1
:End
:r2
:End
:
:DispGraphClrDraw
:getKey(1)-getKey(4)*2+VAsm(E5)≥≥0?Asm(E1)→V,Asm(E1) \ I move 2 pixels
:getKey(3)-getKey(2)*2+HAsm(E5)≥≥0?Asm(E1)→H,Asm(E1) / by 2 pixels
:EndIf getKey(15)
[...->Pic1TILE
.Our animated tiles here
Data(0,2,5,8,10,11...)->GDB1OFST
.I skip the code to draw the entire map
DispTile(X,Y,{{Ytile + Xtile + GDB1MAP} + GDB1OFST} * 8 + Pic1TILE)
:.MAPTEST
:0→Str2→X
:ClrDraw
:38510→Str3
:13→W
:16→H
:{-}8→Y
:For(8)
:sub(SMU
:End
:DiagnosticOff
:Repeat getKey(15)
:If getKey(3)
:sub(SMR
:End
:If getKey(2)
:sub(SML
:End
:If getKey(1)
:sub(SMD
:End
:If getKey(4)
:sub(SMU
:End
:End
:Return
:Lbl SMD
:For(I,0,7
:Vertical +
:X-1*H+Y+Str2→A
:For(B,0,11
:{A+H→A}
:{*2*2*2+Str1+I}→{{L6}+B}
:End
:DispGraph
:End
:Y--
:Return
:Lbl SMU
:Y++
:For(I,0,7
:Vertical -
:X-1*H+Y+8+Str2→A
:For(B,756,767
:{A+H→A}
:{*2*2*2+Str1+I}→{{L6}+B}
:End
:DispGraph
:End
:Return
:Lbl SMR
:sub(CLD
:X--
:For(8)
:Asm(116E962140930E40EBCB1EEB060CCB1E2310FB1C0D20F1
:DispGraph
:End
:Return
:Lbl SML
:sub(CLD
:X++
:For(8)
:Asm(11EE962140960E401DEBCB16EB060C2BCB1610FB0D20F1
:DispGraph
:End
:Return
:Lbl CLD
:X-1*H+Y+Str2→A
:Str3→B
:sub(CLD0
:X+12*H+Y+Str2→A
:sub(CLD0
:0→A
:Return
:Lbl CLD0
:For(8)
:B
:Asm(E5
:{A++}*2*2*2+Str1
:Asm(D1010800EDB0EB
:→B
:End
:Return
:[00000000000000003C4281818181423C3C7EFFFFFFFF7E3C]→Str1
Actually, if you do like pokemon even more, you don't need edge-of-map detection. Just make sure there are enough tiles beyond walkable areas that the user never sees past them, and trigger tiles load in the other maps.
Makes sense, although I'm surprised it crashes rather than behave like the missingno glitch. Although, I guess event tiles (like load map triggers) could be written to have inlined code, and hence a corrupted one could be VERY messy.
How exactly is FF6 different aside from having entirely separate areas? Or, is that what you were referring to?
Also, have we discussed having a seamless overworld (pokemon) or a map based one (Final Fantasy IV/VI)?
Pokemon style movement is pretty traditional for RPGs. It should work fine. :) Also, have we discussed having a seamless overworld (pokemon) or a map based one (Final Fantasy IV/VI)?The way I have it planned, the only limit will be that you can have as many as 256 tiles. So if you made 64 tiles with three frames, then 16 other tiles with one frame, then 8 tiles with six frames, you would be fine. In fact, the method I have won't even require that you have tile data for 256 tiles. If several tiles use the same data, they can all point to the data :) This will be more useful for tiles that we want to look like one frame longer than another (basically, you have it evolve into a tile that looks the same).
Also Xeda,How many frames are you going to allow per animated tile? I don't think we need but 2 or 3.
Yeah, I am assuming that we won't need any more than 256 base tiles, but the number of frames for the animation might exceed 256.You must mean total animation frame for all tiles on screen at any given time. I doubt that we'd ever need 256 frames. Even if you figure all tiles on a give screen are animated that's 24 total tiles per screen. Say each tile has 3 frames (again we really shouldn't need more) that'd be 72 total. Even if you had some tiles overlapping due to some being partially on screen that would only add 9 tiles more (27 additional animation frames) for 99 frames total. If a mask needs another sprite, then you are at 298 frames total. Hmm... I guess it would depend, even though having that many animated tiles (ie all of them) would be highly irregular. Grayscale would be a different story though.
.AXESMTH
[3C4281818181423C→Pic1TILE
[003C424242423C00
[0000182424180000
[0000001818000000
[3C7EFFFFFFFF7E3C
[0000183C3C180000
[0000001818000000
[0000000000000000
Data(0,4,7,8)→GDB1OFST
Buff(384)→GDB1MAP
3→D-3→A→H→V→S-1
For(384)
+1→r1
rand^3→{r1+GDB1MAP
r1
End
While 1
~1
For(10)
+1→r2
~1
For(14)
Pt-On(+1→r1-1*8-(H and 7),r2-1*8-(V and 7),{{VAsm(CB2DCB2DCB2D)+r2*8*3+r1+(HAsm(CB2DCB2DCB2D))+GDB1MAP}+GDB1OFST→r3}+(B^({r3+1}-{r3}))*8+Pic1TILE
r1
End
r2
End
DispGraphClrDraw
getKey(1)-getKey(4)*2+VAsm(E5)≥≥0?Asm(E1)→V,Asm(E1)
getKey(3)-getKey(2)*2+HAsm(E5)≥≥0?Asm(E1)→H,Asm(E1)
A++Asm(CB2DCB2D)→B
EndIf getKey(15)
Generated by the BBify'r (http://clrhome.org/resources/bbify/ (http://clrhome.org/resources/bbify/))
Looks great Xeda! Why does the animation speed slow down in the second part of the screen shot though? ???Initially, I use a delay of 8192 (2^13) for the animation speed. Every time the screen is moved, I add 1024 to the delay counter (because that is about how long it takes to shift the screen). In the later part of the screenshot, when I shorten the delay to 1024, this means that every time the map is scrolled, it gets updated and the timing is slightly off.
That version in the screenie updates the LCD every single frame, even if nothing has changed. The grayscale tiles update every frame, the ones in the middle-ish of the map update every 5 frames and the ones on the outer edge update once every 16 frames. I'm pretty sure speed won't be an issue, and even if I add the variable speed to the Axe version, it will only add a thousand cycles or less (still keeping it >60FPS). I am still trying to figure out a more clever and efficient method for this, though. It will be particularly difficult to smooth scroll the map with masking and a player sprite on it x.xI forgot that grayscale would be updating every frame regardless... x.x wasn't thinking lol. Even if it slows down to 40, that's still fine. A lot of games slow down when a lot of things are being updated on screen.
But writing enemies' AIs will surely be a PITA (which skill use when, on who etc).That can be alleviated some by having different selectable styles, IE set an AI to healing, attacking, supporting etc. I do still agree with you though, and even a smart AI isn't as good as something you can control yourself.
You mean applying monsters' decisiveness to guys of your team ? That effectively can be a good idea for total newbies.Yes, precisely :) It shouldn't be that difficult if we already have the AI made.
We can't do anything with that, all ASM code must be Axe-friendly.I know, but I thought I would post it to see if there were any routines that are desired (the jump table is currently empty). I can also write simple Axe routines such as :
Lbl IRCTI
.x,y,w,h
Lr1Asm(5623235E23234E232346C38640)
4086 is probably not going to be the actual address, but routines like this should be fairly easy to create. As well, the text routines can be modified to use the OS penRow and penCol to make text coordinates easier to manipulate. Otherwise, string displaying would be:Str1Asm(CD8640)
(again, the adress will likely be changed).
FOr the Battle engine, I making one. I'll sure need help, but when done, you'll have a powerful and beautiful engine!I'm already working on it actually. What we can do is do our battle engine, then show it to other team members for them to choose one. What do you think of that ?
drawtile:
ld de,gbuf
ld hl,tile
ld bc,8
ldir
As well, LCD updates are pretty small and gives you more time for things like grayscale.
The thing is that then, all Axe graphical commands will be unefficient with that method, and since Axe provides a fair lot of them ... You or anyone else (certainly not me, I can't do that) will have to rewrite from scratch all graphical routines the whole game would use to work with vertical buffers. I think that's an enormous time-eating task x.xI have line, circle, rectangle, pixel, sprite (clipped), tile, text, menu, LCD updating, grayscale, tilemap. Anything else?
Using two sets of routines doing the same thing with differently aligned buffers is a huge waste of space. You'll have either to make your tilemapper work with horizontal buffers and use Axe's graphical routines, or replace all Axe's graphical routines by yours with an axiom and all the project will only use your axiom to work with vertical buffers.So, does this mean that battles and stuff will happen on the tilemap? I thought they would occur on their own setting, allowing you to use horizontal buffers for battle and vertical buffers for displaying the tilemap.
The only problem I have is the last bullet. I feel like the attack animation should not be restricted to sprites. Instead, I think attacks should be subroutines so that we can make attacks that are customised for graphics and whatnot. For example, a thunderbolt animation might strike several places on the field before attacking a character. Using sprites for this would take a lot of memory, whereas using existing routines for lines and stuff would be a lot smaller.It's exactly what I meant <_< for example, an attack data would look like this :
At last, there's the animation. It has a number of frames, and as many sprites as the number of frames.
I don't see a huge issue with dropping support for 83+BE models. It allows us to increase the speed by 2.5x, and have significantly more space to work with, and it's a fairly small subset of the community.
Matrefeytontias, there is plenty of room for an extra 1800 bytes of graphical routines, especially if it makes it significantly faster.
I thought programming wise, there was no difference between 3 and 4 level gray.Well it is different. In both case you have two bits (not learning you anything, if you want 3 or 4 values, you need 2 bits) for each pixel (so two buffers).