Omnimaga

Calculator Community => Other Calc-Related Projects and Ideas => Topic started by: willrandship on December 06, 2012, 12:11:45 am

Title: OmniRPG - Coding
Post by: willrandship on December 06, 2012, 12:11:45 am
So, here's the topic where we'll discuss the coding of the game.
Title: Re: OmniRPG - Coding
Post by: Sorunome on December 06, 2012, 12:15:50 am
with the irc discussion everybody wanted axe and compile as an app and use appvars as data files, lol
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 06, 2012, 12:43:56 am
I think Axe with the possibility of some assembly would be the way to go.
Title: Re: OmniRPG - Coding
Post by: willrandship on December 06, 2012, 02:09:04 am
Axe+Assembly is fine with me, as long as we have enough coders (which, it appears, we do, so :D)

Assembly can be easily inlined into it by simply having axe include a file with the hex inside. That way, compilation is still as simple as compiling the main program.

Speaking of the main program, what should the naming convention for files be?
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 06, 2012, 06:26:17 am
I think something like this:
ABTLENG
AMAIN
AMAP00
AMAP01
AMAP02
...
The map files would actually be data for specific maps, like information about where people are, what they say/do, and where you might enter to another map (like if you enter a dungeon or shop).

I voted Axe+Assembly since it seems many people would prefer Axe and I can help out with assembly :3
Title: Re: OmniRPG - Coding
Post by: aeTIos on December 06, 2012, 07:01:27 am
I can help with routines. We need a list of which routines we need, though.
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 06, 2012, 07:35:00 am
I think axe + asm is fine... Yes now we need a list of all routines...
Title: Re: OmniRPG - Coding
Post by: Augs on December 06, 2012, 12:14:32 pm
What is OmniRPG? What platform?
Title: Re: OmniRPG - Coding
Post by: Scipi on December 06, 2012, 12:16:56 pm
A community project :D

http://ourl.ca/17697 (http://ourl.ca/17697)
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 06, 2012, 12:17:51 pm
It's a large rpg where a lot of omnimagers are gonna work on, everyone can join
It's gonna be axe with some asm routines
Title: Re: OmniRPG - Coding
Post by: Augs on December 06, 2012, 02:48:52 pm
Ok, I am out because I can't program on that platform
Title: Re: OmniRPG - Coding
Post by: Scipi on December 06, 2012, 02:51:36 pm
Ok, I am out because I can't program on that platform

There's more to it than just coding. I mean, I don't even know Axe and I'm working on story, systems, and map design :P
Title: Re: OmniRPG - Coding
Post by: epic7 on December 06, 2012, 04:49:20 pm
And potentially computer version, a Homer mentioned earlier
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 06, 2012, 04:51:50 pm
Ok guys, shouldn't we discus what's gonna be coded by who and how it should be coded? Like in example: movement, 1px at the time? 8px at the time with smooth scrolling? That kind of stuff?
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 06, 2012, 05:06:04 pm
Yeah, I said in one of the other topics that if I somehow find time during the weekend, I want to try to write up a proof-of-concept map engine. Once we actually have a map engine working, we will probably figure out scrolling. I was thinking of 16x16, 3-level gray tiles. I think that offers much better detail and the user can feel more at the world level. I was also planning on incorporating a collision detection scheme that I was working on by making a simple AI to chase down the user.
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 06, 2012, 05:14:32 pm
Yeah i read the post ;)
Guys, we're up to some amazing things this weekend... Xeda is gonna blow our minds
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 06, 2012, 05:17:17 pm
Hehe, the pressure is on XD
Title: Re: OmniRPG - Coding
Post by: willrandship on December 06, 2012, 07:34:21 pm
Sounds exciting! 16x16 is big, but it does give a lot more freedom with graphics.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 07, 2012, 08:05:51 am
I was looking at Slova (http://ourl.ca/15059/273677) by HotDog and that is basically what I have in mind, except grayscale o.o We need to get chickendude in on this; ze is an excellent assembly programmer o.o
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 07, 2012, 08:09:55 am
Actually scrolling maps isn't that hard (in axe) but still my routines are very slow i think xD so yeah use chickendude's :p
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 07, 2012, 08:32:43 am
I am about to send a PM to chickendude detailing my coding plan. Basically, I think I can optimise it quite a bit (maybe 200 to 100 times per second it can be rendered) by keeping a mask that I rotate with the map. Then, for left/right rotating, I just shift the screen left/right, apply the mask to the tiles with AND logic and if Z is returned, draw a pixel off, if NZ is returned, draw the pixel on. Since I am planning on 3-level gray, I will need to do this on two buffers, but even then I think it will be pretty fast. As well, since it is 3-level gray that I am planning on, I will need to rotate the grayscale mask as well. Since it is 3-level gray, that will be very easy.

By my calculations, before I do any coding, shifting the screen one pixel takes about 22000 cycles, if I remember correctly, then to test each of the sprites and draw accordingly (with optimised assembly), that will take at most 3000 cycles. On two buffers, this will be about 50000 cycles total. At 6MHz, that is 120 times it can be drawn per second (not updating the LCD). At 15MHz, that is 300 times per second. that should make the grayscale still smooth :) Also, shifting up and down will be much, much faster. Probably one or two thousand cycles for both buffers which is 25 to 50 times faster XD

I hope my calculations are correct ._.
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 07, 2012, 08:38:35 am
If those calculations are correct that would turn out to be a very impressive scrolling map :P
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 07, 2012, 08:41:42 am
hehe, yeah, I sure hope so. And it seems that squidgetx has corroborated my guestimate of 22000 cycles for shifting the screen.
Title: Re: OmniRPG - Coding
Post by: squidgetx on December 07, 2012, 10:15:28 am
Don't forget that calling DispGraph^r takes like 59,000 cycles which drops your framerate from 120 down to around 50-60fps :P

Anyway, what I'm concerned with isn't shifting the screen, but with drawing things on the map that don't scroll, like your character and any enemies. The easiest, most flexible, but slowest solution is to back up both buffers, draw those entities, dispgraph, then recall the buffers. The faster, but hardest solution is to use something like Pt-Get (I don't know how fast that routine is, but it's going to be much slower than any kind of aligned copying) to back up only those select areas of the screen where you and/or your enemies are. The problem with that method is that the player will see some visible lag (and possible deterioration in gs quality) when there are multiple enemies on screen, and that it will be slower than the first method in certain cases with multiple unaligned enemies. Again, if you're OK with sticking to 15mhz, then this is a non-issue (and I would use the first method in that case)

Also, if the character and enemies are going to be masked sprites, that's not going to be 3000 cycles per sprite.

Not trying to ruin the party here, but I literally have been just dealing with these problems in A:P
Title: Re: OmniRPG - Coding
Post by: aeTIos on December 07, 2012, 10:24:34 am
A.K.A, no grayscale. I don't care for grayscale actually, and the games I made lately (not published since bullshit and just like only 2 in the latest 6 months) don't use grayscale. (they don't look nice either but that's another story. And no, I can't put them up here since 1. I deleted them and 2. My USB port is fried)
Title: Re: OmniRPG - Coding
Post by: Yeong on December 07, 2012, 10:37:13 am
Greyscale is not necessary. Look at Verdante Forest. It was wonderful piece of game without greyscale. :D
Title: Re: OmniRPG - Coding
Post by: squidgetx on December 07, 2012, 10:38:51 am
It's just a bit of a conundrum...the real challenge that Axe gray provides is that you have to do twice the screen work twice as fast. Think about the difference in how much code you can put into a 30fps monochrome game vs a 50fps grayscale one. That's why most asm games that use grayscale use crystal timer interrupts :P
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 07, 2012, 09:43:00 pm
I believe Xeda's engine is ASM anyways. As I stated in the sprites thread, I really don't think grayscale is a necessity (although it would be nice). I would also like to keep this project 6 Mhz, so that it can run on all models. Oh, and in regards to grayscale, regular interrupts can and have been used successfully in ASM. Desolate by Tr1p1ea is one example. Jim E from Revsoft also developed a grayscale library called Revolution Grayscale package. It also uses interrupts and was based on the one used in Desolate.
Title: Re: OmniRPG - Coding
Post by: tr1p1ea on December 07, 2012, 10:31:30 pm
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.
Title: Re: OmniRPG - Coding
Post by: Sorunome on December 07, 2012, 11:26:20 pm
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
Title: Re: OmniRPG - Coding
Post by: willrandship on December 08, 2012, 01:54:38 am
You mean this one, right? http://www.ticalc.org/archives/files/fileinfo/421/42148.html (http://www.ticalc.org/archives/files/fileinfo/421/42148.html)

@Tr1p1ea I don't think it would be too much data, if you're just referring to storage space, since we'll be using external appvars for large parts of the storage. We could store most of the sprite data there. 8 lvl grey is a little excessive, though.

What if we made it 3 level gray, but only the background used the back layer? All sprite work would be done in monochrome, so everything but scrolling and updating the screen only works on one buffer, but we still get the pretty area maps and whatnot.
Title: Re: OmniRPG - Coding
Post by: Sorunome on December 08, 2012, 01:55:48 am
yeah, exactly! :D
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 08, 2012, 07:53:53 am
So, I posted this in the sprites topic (this is something chickendude was working on): (http://revsoft.tifreakware.net/phpBB3/download/file.php?id=89)
Monochrome here looks pretty snazzy and I like the masking. If we kept it at 3 or 4 level gray, I am thinking each 16x16 sprite would be 128 bytes.

1 layer for masking
2 layers for the gray sprite
1 layer for collision detection

Because of this, monochrome is probably better and it will free up a buffer for collision detection .__.
Title: Re: OmniRPG - Coding
Post by: Sorunome on December 08, 2012, 12:51:31 pm
that is looking actually pretty good. BUt wouldn't greyscale still be possible like that on 16MHZ?
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 08, 2012, 05:24:21 pm
* 15MHZ...?

I guess it should be possible... But they're discussing if they would do something like auto detect MHZ so 15 = grey , 6= mono
Or something like user choice...
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 08, 2012, 05:57:01 pm
Yeah, I think there should be an option for grayscale. If you turn grayscale on, the calc will attempt to work at 15MHz. If you use monochrome, the calc will be put at 6MHz. If the calc is capable of 15MHz, it will start with grayscale by default.

Anyways, I started a little coding, just to get the idea flowing. It is actually being more of a pain than I thought it would be, especially because I am trying to make sure it is Axe compatible XD I also used some simple sprites and a simple tilemap to test the engine, currently (it only shifts left or right and I removed the code to check for the edge of the map). It allows for variable sized tilemaps as well, and it can start at different offsets into the tilemap :D


EDIT:
In the main topic, we have been discussing using Matrefeytontias' Axiom that will allow us to access routines in apps (so kind of like a shell). Since this project will be big and we can program in some highly optimised routines in an app, I was thinking we should go for it. This will also mean we can directly use assembly and create routines to directly access Archive (so we can keep sprites and tilemaps in archive, maybe even the App).
Title: Re: OmniRPG - Coding
Post by: Sorunome on December 08, 2012, 07:21:39 pm
In my opinion we should go for app as it doesn't require a shell to run, and then, as you said, load stuff out of archive.
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 08, 2012, 07:41:48 pm
Ok xeda idk but i think you're code isn't at it's max capabilty...?

And yeah i think it should be an app, with the axiom for routines and archived stuff
Title: Re: OmniRPG - Coding
Post by: Sorunome on December 08, 2012, 07:43:16 pm
but aximos would kill the awesome feature that you don't need a other shell to run it
Title: Re: OmniRPG - Coding
Post by: squidgetx on December 08, 2012, 07:46:33 pm
Axe already has some pretty good routines to work with archive, I don't think you'll need custom asm for that. Also axioms don't make you need another shell to run.
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 08, 2012, 07:48:20 pm
Sorunome: if it's an app... You wouldn't need a shell...
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 08, 2012, 07:48:42 pm
Axioms don't make it so you need another app or program to run, it only means that you need them to compile the source.

Also, @stevon8ter: The program starts off with a Pause 100 at 6MHz. keep watching and I remove the Pause 100 and show its speed, then I show it at 15MHz. At 15MHz, WabbitEmu tells me I am getting 80 FPS and 60FPS at 6MHz.  I think we should keep it at 6MHz for the main engine and routines so that it stays nicely compatible with the 83+
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 08, 2012, 07:50:09 pm
Oooh ok, sorry but i'm on ipod so it could look a bit slower for me xD
Title: Re: OmniRPG - Coding
Post by: Sorunome on December 08, 2012, 07:52:11 pm
Oh, i thought it also needs the axiom to running, three people confirmed now the other XD
so, why not use epic axioms?
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 08, 2012, 07:58:26 pm
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 etc
Title: Re: OmniRPG - Coding
Post by: Sorunome on December 08, 2012, 07:59:26 pm
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 etc
lol, that was a retorical question stating that we could use axioms then for such stuff
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 08, 2012, 08:01:34 pm
Ooooooh ok now that i read it again it makes sense, sorry xp
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 08, 2012, 08:20:47 pm
Well, I figure that if we use an app, we can have more code space (16KB and an 8KB program). We can still use axioms and use an app :P
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 08, 2012, 09:39:57 pm
  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
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 09, 2012, 07:43:20 am
I started working on scrolling in the up/down direction, and it is a pain o.o I have to keep track of how far up/down it is scrolled and left/right so that I can shift in new content appropriately .__. I rewrote the right/left shifting, too and I believe it is faster, but I'm not suree (I had a better idea last night, so I don't need the IX register). Also, I have a bug somewhere in the code, apparently, because the program is doing weird stuff to my calculator every so often. On the plus side, I fixed the scrolling bug for left/right >.>

On another note, if we decided to do text compression, I have a nice algorithm for that. I was thinking this morning that I could make a Python program to read a .txt file and spit out the compressed data in assembly format.

EDIT: It is still about 60FPS at 6MHz, a few extra frames per second for shifting up/down.
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 09, 2012, 07:46:07 am
Wow Xeda, it really is faster now :D and tell me your idea...? (maybe pm? ) maybe i could help you develop something to compress text? But mine would be done in c# but whatever, if i get the idea, i might be able to help...?
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 09, 2012, 08:21:06 am
I'll describe it here, since I don;t think I ever released the idea, just the code. Basically, it works like this (there are two methods)

I first designed this algorithm using Celtic3+BASIC, using the idea of how common certain letters were in the English alphabet. I arranged them in order and threw in some numbers and punctuation, so I could compress my most common messages:
Code: [Select]
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):
NOTE: We start counting at zero.
H is the 9th character, so it is one nibble, $8
E is the 2nd character, so it is one nibble, $1
L is the 12th character, so it is one nibble, $B
O is the 5th character, so it is one nibble, $4
! is 30th character, so it is two nibbles: $EF
Combining the nibbles, we get 81BB4EF, but we need to store bytes, and this is an odd number of nibbles, so we pad it with a 0. This is why a space is the first character, because decompressed, it would put a space at the end in cases like this.

Anyways, that is 4 bytes, compared to 6, so compression was about 67% In BatLib, to make sure the extra space at the end wasn't in the output for decompression, I compress data and store the original size as a two byte value in the beginning.

Now, why did we use 46 chars? The first 14 are used as 1-nibble values. A nibble can be 16 different values, so this leaves two extra nibbles for our "extended" chars. So 2*16=32, which means we can have 32 two-nibble values and 14 nibble values, totaling 46. Indexing at 0, we have chars numbered 0 to 45, which in hex is 00h~2Dh. If you look at what we add to find the value of 2-nibble chars ($D2), it is actually not a coincidence that it is the value 2D with its nibbles swapped :D

So what if we want to compress something other than text? What if it is arbitrary data? Basically, you need to scan the data to figure out which byte values are used, then you need to arrange them in descending popularity (I call this a "compression key"). Find your cut-off value (the number you add to get the two -nibble values) and this will also tell you your cut-off for one-nibble/two-nibble values. Because this will use a unique set of chars in some order, you will also need to include the "compression key" so that you can decompress. If the data isn't large enough, the compression key plus the compressed data will take up more space than the original.

I used this in BatLib to compress some internal data, like the main menu (the bitmap was compressed a few hundred bytes, including the compression key). You can also apply this algorithm several times in some cases to further compress the data. I got one tilemap to compress down to 12% of its original size, with each of the compression keys included!

EDIT: This is the relevant code in BatLib for most of the compression/decompression functions:
Spoiler For Spoiler:
Code: [Select]
CompressStr:
     call LoadInc
     ld hl,Codec1
     dec a
     jr nz,$+5
     ld hl,Codec2
     jr $+5
CompData:
     call CustCodec
     ld (TempWord2),hl
     call StringOrName
     ld (TempWord1),hl
     push bc
     push af
     push hl
     inc bc
     inc bc
     call MakeAnsStrX
     pop hl
     pop af
     pop bc
     ex de,hl
     ld (hl),c
     inc hl
     ld (hl),b
     inc hl
     ex de,hl
     push bc
     push de
     call ReadArc
     pop hl
     pop bc
     push hl
     push de
     ld de,(TempWord1)
     ld ix,(TempWord2)
     call TextComp
     pop de
     inc hl
;HL points to the end of where it was converted
     ex de,hl
     or a
     sbc hl,de
     ex de,hl
;DE is the size of the data to delete
;HL points to where to delete the data
     push hl
     bcall(4357h)
     pop hl
     pop de
     dec de
     dec de
     or a
     sbc hl,de
     ex de,hl
     dec hl
     ld (hl),d
     dec hl
     ld (hl),e
     ret

TextComp:
;Inputs:
;     DE points to the text to convert
;     HL points to where to convert to
;     BC is the size of the string
;     IX points to the codec
     call CodecStats
     ld (8478h),bc
     ld b,0
     ld (hl),0
TextCompLoop:
     push hl
     push bc
     ld bc,(8478h)
     ld a,b \ or c
     jr nz,$+11
       pop bc
       pop hl
       bit 0,b
       ret z
       xor a
       rld
       ret
     dec bc
     ld (8478h),bc
     ld a,(de)
     inc de
     ld c,(ix)
     push ix
     pop hl
     inc hl
     cpir

     push hl
     push af
     ld a,(ix)
     dec a
     ld h,a
     pop af
     ld a,h
     pop hl
     
     jr z,$+3
       ld c,a
     sub c
     pop bc
     pop hl
     exx
     cp c
     exx
     jr c,$+23
     exx
     sub b
     exx
     rlca \ rlca \ rlca \ rlca
     rld
     rlca \ rlca \ rlca \ rlca
     inc b
     bit 0,b
     jr nz,$+4
       inc hl
       ld (hl),0
     rld
     inc b
     bit 0,b
     jr nz,TextCompLoop
     inc hl
     jr TextCompLoop-2
Codec1:
;46 chars
; ETAOINSHRDLCUMFGYPBVKWXJQZ,?!.0123456789/-:'
 .db Codec1End-Codec1
 .db 29h,"ETAOINSHRDLCUMFGYPBVKWXJQZ",2Bh
 .db $AF,2Dh,3Ah,"0123456789",83h,71h,3Eh,$AE
Codec1End:
Codec2:
;Includes lowercase tokens
 .db Codec2End-Codec2
 .db $29,$BB,$45,$B4,$54,$C4,$41,$B0,$4F,$BF,$49,$B8,$4E,$BE,$53,$C3,$48,$B7,$52,$C2,$44,$B3,$4C,$BC
 .db $43,$B2,$55,$C5,$4D,$BD,$46,$B5,$47,$B6,$59,$C9,$50,$C0,$42,$B1,$56,$C6,$4B,$BA,$57,$C7,$58,$C8
 .db $4A,$B9,$51,$C1,$5A,$CA,$2B,$AF,$2D,$3A,$30,$31,$32,$33,$34,$35,$36,$37,$38,$39,$83,$71,$3E,$AE
;need 4 more bytes
 .db 3Fh,82h,70h,$B0
Codec2End:
CustCodec:
     call StringOrName
     ld de,86ECh
     push de
     call ReadArc
     pop hl
     ret
DeCompStr:
     call LoadInc
     ld hl,Codec1
     dec a
     jr nz,$+5
     ld hl,Codec2
     jr $+5
DeCompData:
     call CustCodec
     ld (TempWord2),hl
     call StringOrName
     or a
     jp nz,ARCH
     dec bc
     dec bc
     push bc
     ld c,(hl)
     inc hl
     ld b,(hl)
     inc hl
     push hl
     inc bc
     call MakeAnsStrX
     ld (TempWord1),bc
     pop hl
     pop bc
     push de
     ld ix,(TempWord2)
     call TextDeComp
;DE is the size of the data to delete
;HL points to where to delete the data
     ex de,hl
     ld de,1
     bcall(4357h)
     pop hl
     dec hl
     dec hl
     ld a,(hl)
     dec a
     ld (hl),a
     inc a
     ret nz
     inc hl
     dec (hl)
     ret
CodecStats:
;     IX points to the codec
;        codec format is the first byte is the size, followed by the bytes allowed
;Output:
;     B' is the adjusting value for one-byte values
;     C' is the cut-off for half-byte values
;     A is the same as B'
     di
     exx
     ld a,(ix)
     rlca
     rlca
     rlca
     rlca
     and 15
     ld b,a
   ld a,(ix)
   and 15
   add a,b
   and 240
   jr z,$+3
   inc b
     ld a,16
     sub b       ;
     ld c,a      ;number of half nibbles
     ld a,b
     rlca
     rlca
     rlca
     rlca
     or c
     ld b,a
     exx
     ret
TextDeComp:
;Inputs:
;     HL points to the text to decompress
;     DE points to where to convert to
;     BC is the size of the string
;     IX points to the codec
     call CodecStats
     ld (8478h),bc
     ld b,0
TextDeCompLoop:
     call GetNextNibble
     ld a,c
     exx
     cp c
     exx
     jr c,$+15
       ld (de),a
       call GetNextNibble
       ld a,(de)
       rlca \ rlca \ rlca \ rlca
       or c
       exx
       add a,b
       exx
     push hl
     push ix
     pop hl
     inc hl
     add a,l
     jr nc,$+3
     inc h
     ld l,a
     ld a,(hl)
     pop hl
     ld (de),a
     inc de
     push bc
     ld bc,(8478h)
     ld a,b \ or c
     pop bc
     jr nz,TextDeCompLoop
     ret
GetNextNibble:
; z flag set if the last
     xor a
     inc b
     bit 0,b
     jr z,$+8
     rld
     ld c,a
     rrd
     ret
     rrd
     ld c,a
     rld
     push bc
     ld bc,(8478h)
     dec bc
     ld (8478h),bc
     pop bc
     inc hl
     ret     
GetCodec:
     call StringOrName
     or a
     ret nz
     or b
     or c
     jp z,NO_DATA
     call CountBytes
     call MakeAnsStrX
     dec bc
     ld a,c
     ld (de),a
     inc de
     ld hl,88ECh
     ldir
     ret
CountBytes:
     push hl
     push bc
     xor a
     ld hl,86ECh
     ld (hl),a
     ld d,h
     ld e,l
     inc de
     ld bc,2FFh
     ldir
     pop bc
     pop hl
GetCodecLoop:
     push bc
     ld e,(hl)
     ld d,0
     ex de,hl
     add hl,hl
     ld bc,86ECh
     add hl,bc
     inc (hl)
     jr nz,$+4
     inc hl
     inc (hl)
     ex de,hl
     pop bc
     cpi
     jp pe,GetCodecLoop
     call Order
     ld b,0
     inc bc
     ret
Order:
     di
     ld hl,86ECh     ;points to the density list (512 bytes)
     ld de,88ECh     ;points to where the output is
     ld bc,0
     ld (TempWord1),hl
     exx
     ld hl,0         ;MaxVal
     exx
OrderLoop:
     push bc
     ld c,(hl)
     inc hl
     ld b,(hl)
     inc hl
     push bc
     exx
     pop de
     or a
     sbc hl,de
     add hl,de
     jr nc,$+3
       ex de,hl
     exx
     pop bc
     djnz OrderLoop
     ld hl,(TempWord1)
     exx
     ld a,h
     or l
     exx
     ret z
     xor a
OrderLoop1:
     push bc
     ld c,(hl)
     inc hl
     ld b,(hl)
     push bc
     exx
     pop de
     or a
     sbc hl,de
     add hl,de
     exx
     pop bc
     jr nz,$+12
       ld (de),a
       inc de
       ld (hl),0
       dec hl
       ld (hl),0
       inc hl
       inc c
       ret z
     inc hl
     inc a
     djnz OrderLoop1
     ld hl,(TempWord1)
     jr OrderLoop-5
Title: Re: OmniRPG - Coding
Post by: aeTIos on December 09, 2012, 08:46:28 am
Are there any other things to do? I'd like to code some stuffs.
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 09, 2012, 08:48:22 am
So if i get it right, the '.' would be $F0 ? or $F1 ?
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 09, 2012, 08:51:21 am
@stevon8ter: yep :)
@aeTIos: I dunno, I just started experimenting with stuff. I don't think we even have a plan of what there is to do .__. We should keep the first post edited with a To Do list as well as the people working on the different parts.
Title: Re: OmniRPG - Coding
Post by: aeTIos on December 09, 2012, 08:52:24 am
Just try in Axe: text(0,,241)
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 09, 2012, 08:53:41 am
@aeTIos: He means using the compression algorithm I gave. '.' corresponds to the two-nibble value $F0
Title: Re: OmniRPG - Coding
Post by: aeTIos on December 09, 2012, 08:54:11 am
Oh nevermind in that case :p
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 09, 2012, 08:59:41 am
Yeah :p

And we should indeed keep track of a to do list, many people are asking what they can do but noone has a concrete plan. Xeda is the only one who actually coded something for this already

EDIT: xeda , you say there are 46 chars... but for now there are 45 right? with a possiblitie for a 46th char...?
Title: Re: OmniRPG - Coding
Post by: aeTIos on December 09, 2012, 09:05:32 am
Well I can imagine a lot of things that I could already do. Just not sure if they're really needed since it's still in planning stages.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 09, 2012, 09:06:26 am
Cool, what ideas do you have?
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 09, 2012, 10:03:59 am
So xeda, for the compression, it would be something like:

??
Title: Re: OmniRPG - Coding
Post by: Yeong on December 09, 2012, 10:42:09 am
also iirc xeda once mentioned that she can store 8 switches (switches are crucial in RPG and it helps manage events) in a 2 bytes number. It should help data size be smaller :D
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 09, 2012, 10:46:48 am
Yeah could be nice :D

If all turns out well... I could create a map-designer-tool as well... and some other stuff that could be handy
Title: Re: OmniRPG - Coding
Post by: Yeong on December 09, 2012, 10:47:51 am
it's a bit silly question... but are we having sound in this game? /me points to MuseInc :P
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 09, 2012, 10:48:30 am
As cool as that might be, I'd say no. :P
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 09, 2012, 10:49:56 am
At first i'dd finish the game itself... if speed turns out well... we could adjust it a bit so we have a [2nd] version with music...

But first we'll have to finish the game
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 09, 2012, 10:58:27 am
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).
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 09, 2012, 11:03:03 am
Ok sorry didn't know and didn't see in other topic, sorry

yeah looks not to bad :p
Title: Re: OmniRPG - Coding
Post by: epic7 on December 09, 2012, 11:12:36 am
Although its kinda unnecessary, musical would be really awesome :P
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).
That's one fancy Lazor! O.O
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 09, 2012, 11:54:26 am
@stevon8ter: I couldn't run it .__.
@Yeong: I think we shouldn't have background sound, but we could incorporate sound/music as a non-crucial part of the game. For example, we could have a "radio"  in the game that plays from a random playlist.
@Matrefeytontias: That looks nice o.o If you could make it so that it can start of a position (x1,y1) and stop at position (x2,y2), that would be great o.o (This would be so that we can have the laser be fired from the player and have it hit the opponent, or miss and shoot off the edge of the screen.)
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 09, 2012, 11:56:45 am
Yeah I can do that, but I'll have a hard time with the sinusoidal trajectories of the small squares around the laser :/

Might we create an "OmniRPG - Animations" thread, since animations are different of sprites ?
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 09, 2012, 12:07:51 pm
@xeda ow sorry :/ it needs .net framework 4.0 i think. Idk
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 09, 2012, 12:18:24 pm
Yeah, that might actually be a good idea Matrefeytontias. Otherwise, animation ideas will get lost in the sprite/coding sections.
Title: Re: OmniRPG - Coding
Post by: shmibs on December 09, 2012, 03:54:38 pm
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).

that's a lot of code for a single animation, and, if it takes up the entire screen, how will you see what's shooting/being shot?
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 09, 2012, 04:05:01 pm
For the code you're right (I didn't optimize though), but there are little squares that are going from the shooter to the shooted.
Title: Re: OmniRPG - Coding
Post by: Sorunome on December 09, 2012, 04:19:13 pm
can you maybe scale it down a bit?
Title: Re: OmniRPG - Coding
Post by: shmibs on December 09, 2012, 04:37:20 pm
matrefeytontias: i know that the direction is indicated; what i meant was that the animation is the only thing that can be displayed on the screen at once because it uses screen shift commands, so it wouldn't work for being overlayed on a battle scene.
Title: Re: OmniRPG - Coding
Post by: willrandship on December 09, 2012, 07:46:48 pm
Holy crap that engine looks amazing. With graphics like that I don't mind monochrome at all ;D

I don't see why we should include sound if we're worrying about people having a shell or not......:P

@Shmibs, so the laser attack would shake the screen too...I don't see a downside....
Title: Re: OmniRPG - Coding
Post by: tr1p1ea on December 09, 2012, 08:55:27 pm
Will this project require animated tiles?
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 09, 2012, 09:09:40 pm
I was working on a separate engine to handle animated sprites :D Also, if I have it so that it smoothscrolls 8 pixels at a time, I can get rid of the difficult parts of the tilemap engine. (Basically, if you move left, it will scroll in 8 times, kind of like how Pokémon does it).

@tr1p1ea: For the animated tiles, I was thinking of having a format like this:
Code: [Select]
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.

This will make it very easy to have tiles animated at different speeds, without keeping a timer for each tile. It will also allow for arbitrary speeds, like some tiles could move every frame and others could move every 3 or 5 frames. It will also mean that you can keep a low number of base tiles for the actual map data (like 16, for nibble packing), but still use 256 tiles in all (or more).
Title: Re: OmniRPG - Coding
Post by: willrandship on December 10, 2012, 02:25:49 am
That actually sounds pretty cool. So, if you're walking in one direction it would stay continuous, but you would have to wait for it to finish scrolling to turn around?
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 10, 2012, 07:22:51 am
Precisely, and if we went that route, coding would be much easier, with a lot less error checking. I found out my first final doesn't start until tomorrow, so I will try to get to writing up a better engine :3
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 10, 2012, 08:06:33 am
+ collision detection is way easier and smaller... :D

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...
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 10, 2012, 08:18:52 am
+ collision detection is way easier and smaller... :D

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...
Yes, 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.
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 10, 2012, 08:21:55 am
well yeah that's what i mean :p so if you for example have 5walkable tiles, they are, 0,1,2,3,4  so you say if {tile-to-move-to} < 5
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 10, 2012, 08:37:20 am
I coded a very simple (and a bit optimised) smooth-scrolling engine (after all, I'm at school, thanks to Wabbitemu :P ). It's only 963 bytes, so I thank that we should compare our techniques.

(http://img.removedfromgame.com/imgs/smoothscrolling.gif)

Here's the code :

Code: [Select]
:.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)

Fun fact : I used #ExprOff to optimise this program for size, and the size remained the same ;D
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 10, 2012, 08:45:19 am
Wow, that is awesome o.o
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 10, 2012, 08:52:44 am
Yes it is :o ashame i don't get it xD
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 10, 2012, 09:33:25 am
I forgot to say : it runs at 6Mhz :)

I calculated on IRC that the real engine's code, I mean without datas and without the map filling code, is only 465 bytes :o
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 10, 2012, 09:59:08 am
I modified mine, but it is not nearly as impressive as that o.o Without the tilemap built in, mine is the size of an OS picvar (767 bytes). On the plus side, to shift the map and player position you can do:

sub(SML)  (Shift Map Left)
sub(SMR)  (Shift Map Right)
sub(SMU)  (Shift Map Up)
sub(SMD)  (Shift Map Down)

I also need to optimise the left/right shifting. Since I am going by 8 pixels, I don't need some of the old code for boundary checking. Also, this updates the LCD every pixel it shifts (instead of every 2). The map size is stored in W and H, respectively, allowing for variable sized maps. Scrolling left/right gets 60FPS and scrolling up/down gets 70FPS and it is quite noticeable, the speed difference.
EDIT: I tried scrolling two pixels at a time, too.
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 10, 2012, 10:04:42 am
I don't mind the speed difference, it looks great, you all are such godlike coders :o
(http://darl181.webuda.com/other/woot2.gif)
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 10, 2012, 10:08:08 am
I updated my post with another screenie scrolling at two pixels at a time. Now comes the next step-- animated tiles XD
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 10, 2012, 10:12:12 am
looks very impressive (matref doesn't has 8px smooth scrolling, so maybe code's +- equal? )

(http://darl181.webuda.com/other/woot2.gif)
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 10, 2012, 10:21:00 am
I only have to change the *2 in the two getkey lines to *n to scroll n pixel each frame. Also Xeda, your 2nd screenie is at 15MHz btw ?
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 10, 2012, 10:22:28 am
No, the second is at 6MHz. 15MHz looks like this:
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 10, 2012, 10:22:40 am
Matref: Yeah i know, but then it's not smooth scroll... xeda does it as following... he scrolls 4 times 2 px at a time.. and then waits for next keypress...

you do: keypress: 2px, wait for next keypress..., 2px..
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 10, 2012, 10:23:52 am
@stevon8ter: That is smoothscrolling >.> I should post an example of "hard" scrolling at some point.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 10, 2012, 10:27:30 am
Oh yeah I see. Well, I think I can do that in quite a few code, I'll post a screenshot.

Also Xeda, nice intro effect :D I think that I thought your 2nd screenie was at 15MHz because since you wait for a keypress (which is slow) every 4 frames instead of one, it's faster, right ?
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 10, 2012, 10:29:46 am
No, it is faster because it only updates the LCD every two pixels that are scrolled instead of each pixel (the LCD updating is a major bottleneck for speed).

Now, if I did 4 pixels at a time, I could completely rewrite the left/right scrolling codes to be very fast, but then it would look choppy >.>
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 10, 2012, 10:31:08 am
My engine also updates the LCD each two pixels ... so I think that in fact mine is VEEEERY slow compared to yours :P
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 10, 2012, 10:36:40 am
Yours has the benefit of being much smaller, though. My engine on its own is 646 bytes, almost 150 bytes bigger than yours o.o

EDIT: As an update, I just removed 24 more bytes of code from the left/right shifting. The only impact the code had was to remove 5056 t-states for each pixel shifted left/right (saving about .006741333... seconds at 6MHz, every time the map scrolls 8 pixels >.>)
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 10, 2012, 10:42:11 am
Yeah, but do we want a fast or a light smoothscroller ? I don't think my engine will ever be as fast as yours, but maybe yours will be as light as mine :P
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 10, 2012, 12:35:04 pm
I think speed is more important in this case. We don't know what else will be added that might slow things down.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 10, 2012, 12:49:05 pm
I think of a way of using animated tiles that would fit amazingly on my engine but difficultly on yours :/

The thing is that with our tiles (let's say they are at Pic1TILE), we have a cumulated offset corresponding to the number times 8 you need to add to Pic1TILE to have the right frame of the right tile to be displayed. Let's do some pseudo-code :

Code: [Select]
[...->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)

Let me know if you don't understand something :P
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 10, 2012, 03:43:50 pm
Actually, that would still be easy to do with my map, but I plan to try another method (one I've described before) once I get time. I have exams tomorrow and the next day XD
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 10, 2012, 03:49:06 pm
I've already got exams from thursday.. Till next week tuesday, but haven't felt like learning... Omnimaga distracts me xD
Title: Re: OmniRPG - Coding
Post by: willrandship on December 10, 2012, 06:39:04 pm
So, if we use Xeda's, do we have pokemon-style walking, locking to each tile but smooth scrolling, or would we have smooth movement except when loading the sides?
Title: Re: OmniRPG - Coding
Post by: Sorunome on December 10, 2012, 06:47:03 pm
I would go with totally smooth, not-locked to tiles. :D
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 10, 2012, 06:47:48 pm
You get Pokémon style walking with the engine I made. By the way, here is the updated source (attached to the post). If you want to scroll in any direction, you just need to use sub() and it will update everything. I still need to add code to recognise the edge of the map, though. The code, currently:
Code: [Select]
:.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
Title: Re: OmniRPG - Coding
Post by: willrandship on December 10, 2012, 06:50:20 pm
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.
Title: Re: OmniRPG - Coding
Post by: Scipi on December 10, 2012, 07:48:14 pm
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.

That's exactly what pokemon does. In fact, if you hack the game to see past the areas you aren't supposed to see, the game will actually crash in the original R/B/Y games.

I think pokemon like movement would go well. Else, if it's not too demanding a FFVI like approach could also work well.
Title: Re: OmniRPG - Coding
Post by: willrandship on December 11, 2012, 01:40:52 am
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?
Title: Re: OmniRPG - Coding
Post by: Scipi on December 11, 2012, 02:19:01 am
Quote
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.

The missingno glitch just causes graphical artifacts due to a corrupted stat page. Viewing any normal pokemon stat page will actually fix the problem. With the tiles themselves, I would imagine it would be to an uncaught index out of bounds exception. It would essentially end up reading nonsense data for sprites, animations, events, transition points, NPC's, etc for that area beyond the map. That could cause quite a few nasty effects, and ultimately, a crash :P

Quote
How exactly is FF6 different aside from having entirely separate areas? Or, is that what you were referring to?

In FF VI your movement was non-tile based. Your movement and position was pixel based and was referred to a tiled based map. Much like LoZ is.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 11, 2012, 06:20:08 am
I think Edge-Of-Map detection won't actually be difficult and it would save on map data size. All I have to do is test if X>32767 (meaning it is negative) for the left edge, X+11>H for the right edge, and similar for the upper and lower edges. Either way, I have more shtuff >.>

I woke up at 1:00 or 2:00 (around there) and I couldn't sleep, so I instead came up with an altered idea for animated tiles. Basically, I will keep an LUT that keeps track of the evolution of the tiles, that way, when I load in a new tile, I can use the LUT to see where it has evolved to. Now we can have groups of tiles that will be in the same frame when they are newly loaded in :D However, I have a final exam soon, so I will not be focused on this, yet.
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 11, 2012, 08:23:57 am
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)?

Also Xeda,How many frames are you going to allow per animated tile? I don't think we need but 2 or 3.
Title: Re: OmniRPG - Coding
Post by: Scipi on December 11, 2012, 08:40:50 am
Quote
Also, have we discussed having a seamless overworld (pokemon) or a map based one (Final Fantasy IV/VI)?

Well, so far as the story is working out we will want to convey the idea that this world is quite massive. So a map based overworld would work better for giving that sense of scale as opposed to a seamless one where the "view" of the world is close up to the character and ground and doesn't easily convey landmasses.
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 11, 2012, 08:44:09 am
Mmkay, sounds good to me. :)
Title: Re: OmniRPG - Coding
Post by: willrandship on December 11, 2012, 02:13:41 pm
I like the idea of a big overworld map, but that doesn't restrict us from having internal town maps and the like.

P.S. Best SNES game ever if you love overworld maps: Uncharted Waters. (New Horizons, the sequel, is better)
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 11, 2012, 03:42:34 pm
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)?

Also Xeda,How many frames are you going to allow per animated tile? I don't think we need but 2 or 3.
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).
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 11, 2012, 03:53:03 pm
Ah, good to hear. I was just curious if the engine would have a limit to the number of animation frames per tile or not. :)
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 11, 2012, 03:57:31 pm
Well, since we are using animated tiles, I won't be too surprised if we need >256 tiles o.o If we do, it won't be difficult to add in the ability to handle up to 65536 tiles without having to change the tilemaps at all :)
Title: Re: OmniRPG - Coding
Post by: tr1p1ea on December 11, 2012, 04:33:28 pm
Thats a large tileset! :).
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 11, 2012, 04:46:49 pm
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. Also, I really hope I find enough time to sit down and rework the map engine for 16x16 sprites.
EDIT: *16x16 masked sprites
Title: Re: OmniRPG - Coding
Post by: Scipi on December 11, 2012, 04:59:11 pm
What format will the map data be in?
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 11, 2012, 05:09:20 pm
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.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 11, 2012, 05:35:00 pm
I mean that counting all of the frames of all of the tiles in the total tileset, it could be >256, but the initial frames would total to less than 256 (not just on the screen, I mean in all).

@HOMER-16: I read the tiles going down first, then across.

EDIT: I do this for a good reason, too ! I plan to use my own sprite drawing routine at some point, and it leaves the pointer to the screen data pointing to the next sprite down. This just makes tilemapping a bit faster :)
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 12, 2012, 01:25:46 am
I added animated tiles support to my previous tilemapper, and it works greatly ! Currently the engine is 554 bytes. I'll post a screenshot later (I'm in the bus carrying me to school D: ).
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 12, 2012, 06:41:36 am
Hehe, cool! I only just started adding support. I made a test program first (I still have to add it to the main program) :D

If you check out the screenie, I had to add a big delay between frames :) Also, you will see that there are 4 different kinds of tiles, though they share the same tiles. Some animate between two frames (Filled circle and empty circle or little circle and blank tile), one tile remains blank, and the other tile cycles between the non-blank sprites (black circle, empty circle, little circle). In all, there are 8 frames between 4 tiles and it takes up 72 bytes for the data. Oh, and though this can to grayscale for now, I won't suggest trying it until after I get masked tiles supported. As it is, it is going to be a pain scrolling the screen with masked tiles and a 16x16 character sprite XD (When I show the program without a delay, it flickers, but if you adjust the sprites, it'll look great in gray on an actual calc) No worries, I have an idea of how to make the masking work properly and quickly :) It involves copying 64 bytes to a buffer I am already using (cmdShadow) x.x
Title: Re: OmniRPG - Coding
Post by: tr1p1ea on December 12, 2012, 06:53:20 am
Wow lol, looks really fast. When actual tiles are created and dithered properly it should look great (even the gs).

Top job as usual :).
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 12, 2012, 07:15:21 am
I was experiencing a chocolate high last night (I was really craving chocolate and I got some ^_^) and for whatever reason, I could program that map engine, but it took me about a half hour to figure out how to get the tiles in the right format (after I created the format of all things O_o) I think I am going to have to make an on-calc tile editor for animated tiles, because my syntax really warped my brain. On the other hand, 72 bytes for 8 frames is 8 bytes less than it would have been :) With the method I have, each tile is represented by 3 bytes, then you have all the sprites that take 8 bytes each (for now, it will be 16 later when I add masks). Anywho, I have to go to my final, g'bye :D
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 12, 2012, 07:43:09 am
Awesome work Xeda! :D Good luck on your final!
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 12, 2012, 08:07:52 am
With my engine, each animation is 1 byte + 8 bytes per frame (I'll post screen+code in 2 hours).

Also Xeda, how big is your engine ?
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 12, 2012, 09:57:21 am
Up,

Here's the promised screenshot + code :

(http://img.removedfromgame.com/imgs/smoothscrollingAnimated.gif)

Quote from: Axe
.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/))
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 12, 2012, 09:59:30 am
Wow that's a long pt-on :o i like your and Xeda's

work on it together and make it even greater xD
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 12, 2012, 10:06:56 am
The two programs I have separate are 753 and >500, but they share a lot of the same code, so if I combine them, it will be much smaller (and the actual engine part will probably be >700 bytes in all ._.)  Yours looks quite wonderful, Matrefeytontias o.o Can the tiles work with a different number of frames, or all they all the same number of frames?
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 12, 2012, 11:04:50 am
I use 3 tiles, each with a different number of frames : the first one has 4, the second one 3 and the third 1. The number of frame for the Nth tile is defined by {N+1+GDB1OFST} - {N+GDB1OFST}.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 12, 2012, 11:15:39 am
Oh, I see it now :D I didn't see the 4-cycle tiles. Nice! :D
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 12, 2012, 05:58:23 pm
Okay, my program is getting on the large side, now :/ I have the following done, though:

-Smooth scrolling 1 pixel at a time through 8-pixel steps
-Boundary detection (so that garbage isn't shown if you scroll off the map)
-Animated tiles
-60FPS (It is actually a few FPS faster than before when there wasn't animation o_O)
-Arbitrary map sizes (they can be any width/height from 1 to 65535)

The downside is that minus all the data and stuff, the map engine itself is 1192 bytes (at least I'm pretty sure I removed all the extra stuff .__.)
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 12, 2012, 06:18:45 pm
Still looks cool :0 hmmm if it's only movement, i think we'll defenetly need an app xD (or aren't you tht good at axe? Cause i most of the time have: i use +- good routines but much things that could be optimised, like using r r1-6,...
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 12, 2012, 06:22:37 pm
Well, I'm not too good with Axe and there are ways to optimise this more for size (I was optimising for speed, mostly). I also use about a hundred bytes of optimised assembly, directly XD I think that if I put this all in assembly code in an app, I could make it a little more optimised and maybe even faster (depending on how Axe handles drawing sprites).
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 12, 2012, 09:30:33 pm
Looks great Xeda! Why does the animation speed slow down in the second part of the screen shot though? ???
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on December 13, 2012, 04:37:23 am
Size isn't that much of a problem since if we use my PageSwap axiom, we'll have 40k of executable code with only one app and Crabcake/fullrene.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 13, 2012, 06:10:45 am
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.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 14, 2012, 10:03:11 am
I modified the code I have to use potential sprites (instead of the simple circles). Unfortunately, I messed up on a few frames, so it doesn't look too nice for the tall grass, but I'll leave the spriting to others XD Remember, this will work on the TI-83+ since it is still 6MHz :)

I also was too lazy to finish the map, so I filled it with 0s >.> I should really make use of TileCat or something (I'll probably have to make an on-calc map editor again). Also, as you can see, it uses 8x8 tiles, though a bunch of the tiles are part of a complete 16x16 tile. I have made plans for a tilemap routine that could handle variable size tiles (so you could have 5x5, 11x11, 8x8 , 16x7 tiles all in the same map, for example), but scrolling was too complicated for me to add that in XD It also requires a decent amount of extra RAM :/ (about 200 bytes).
Title: Re: OmniRPG - Coding
Post by: tr1p1ea on December 14, 2012, 04:50:28 pm
Looking good! I dont think arbitrary tile sizes are necessary, especially when this is specifically made with a project in mind.
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 15, 2012, 02:33:56 am
I agree. It really just need to support whatever size we decide that we are going to use. :)
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 15, 2012, 07:51:20 am
Thanks! I will say that it will be slightly more of a pain to use 16x16 tiles, but I think we can use 8x8 tiles to look like 16x16. I wish I was better at spriting and finding good timing for animation XD
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 15, 2012, 09:25:12 am
Posted from cell earlier. I can actually see the screen shot now. Looks nice. :) Why do you think 16x16 would be more difficult?
*Edit* oh, and i wouldn't worry too much about timing. It can fine tuned later. :)
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 15, 2012, 09:34:27 am
Oh, actually coding it to read the data from 16x16 sprites will be a pain for scrolling. I'll probably eventually do it, but it will require a decent amount of motivation for me XD I also have that issue where I like to make sure the program is efficient, so I will need to set aside several days where I can focus on perfecting it XD I'd probably also prefer to do that in actual assembly code.
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 15, 2012, 03:18:03 pm
Ah, ok. Makes sense. :)
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 15, 2012, 07:35:12 pm
I was doing laundry again today, so I brought my calculator and wrote a routine for animated tilemaps (variable speed animating), that uses masked sprites. Since I didn't want to write out a custom LCD updating routine, I ended up using a bcall (EF6A48, whatever it is actually called). I also am using an OS getkey routine (EF4447) and both are slowing it down quite a bit XD Basically, when I get around to cleaning it up with better, faster routines, this will be quite a bit faster o.o As it is, on an actual calc it handles grayscale very nicely (I used an animation scheme of two properly dithered tiles). Here is a screeny, showing the masked nature of the tiles, as well as the variable speed of the animations :D

I figured I would share since this topic is what inspired it :) If I find the courage to convert this to a scrolling tilemap, (and if we go with using an app for some codes like this), I'll be sure to update y'all :)
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 15, 2012, 07:38:07 pm
Wow, variable speeds. I was thinking about this earlier today. Very nice! :D If speed becomes an issue the variable animation speed can probably be dropped though.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 15, 2012, 07:58:28 pm
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.x
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 15, 2012, 07:59:51 pm
Wow that's really nice :D yeah i think there are some other things that are gonna slow it down... Such as all code , sprite... Movement... AI... Like everything that yet has to be implemented in the map routines
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on December 15, 2012, 08:03:45 pm
Yeah, my hope is that we can come up with pretty efficient algorithms that will only slow things down a little. My guess is that at this rate, the most major slowdowns will cause the animation to slow to about 40FPS with a bunch of activity on the screen.
Title: Re: OmniRPG - Coding
Post by: stevon8ter on December 15, 2012, 08:10:04 pm
Yeah but i think we will be able to handle it... I think movement and collision will cause the biggest slowdown, and scrolling as well, but i think you guys could handle that :p cause even with my unoptimised routines i can get a smooth fast scrool-move-collision (b/w no anim)
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on December 15, 2012, 09:12:30 pm
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.x
I 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.
Title: Re: OmniRPG - Coding
Post by: willrandship on December 21, 2012, 07:29:17 pm
Phoenix only runs at 30 FPS, and everybody oohs and ahhs about how smooth it is. :P
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on February 16, 2013, 02:25:32 pm
I modified the source to the animated, masked tilemap routine and it is now 43 bytes larger. I am not sure how much faster this is, but WabbitEmu says it is about 150% faster. Basically, instead of using bcall(4744h), I used direct key testing which cost an extra two bytes but is much faster, and instead of using bcall(_GrBufCpy) (EF6A48), I used a custom LCD updating routine which I believe should be pretty fast and I can make it even faster since it is inline code.

Anyways, see below for what it currently looks like (I took about a 1 second screenshot, so it is on a loop). Now if I can get it to handle scrolling, that would be awesome, but I am pretty sure I will have a difficult time with that. I might be able to get a movable sprite on there, though. Also, the grayscale looks better on an actual calculator.

AMASK is for the most part hexadecimal with some labels (it is meant to be compiled with prgmASMCOMP) and prgmMASKEDTM is the assembly program.

EDIT: I rewrote the program to draw the tilemap while updating the LCD and doubled the speed to about 73 FPS according to WabbitEmu. It is also 27 bytes smaller :) At some point I should make actual tiles for this.
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on February 17, 2013, 08:20:57 am
Awesome stuff Xeda. :D
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on February 17, 2013, 10:33:57 am
I have some sprite movement started :) I don't have actual player sprites, so I just used an 8x8 sprite. I am working on making the data for some sample 16x16 sprites, but once I actually have the data in there, it won't be difficult to add in 16x16 player sprite movements.


EDIT: Also, I need to come up with a less distracting animation XD
Title: Re: OmniRPG - Coding
Post by: chickendude on February 17, 2013, 12:08:27 pm
But that doesn't support scrolling? I don't think you'll have any trouble adding in scrolling, but it might take a big speed hit. I don't think you have to worry so much about speed for this project, though. I also don't understand why you're using masked sprites, especially for 8x8 sprites, having more than one layer isn't going to give you that much more detail unless you want things like bridges and even then i like having larger sprites (16x16) to fit more detail in.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on February 17, 2013, 03:08:39 pm
Yeah, it doesn't support scrolling yet. For all of the things I am thinking about adding, it will probably have its speed cut in half. I think the easiest way to have the sprite display and the LCD updating interleaved will be to have 8x8 tiles, but we can use those to form 16x16 tiles. I am working toward creating a movement engine that features pixel based collision with bottom layer of sprites (the mask) and there will be a buffer holding damage zones for when enemies are on the screen, or anything that can cause damage. So for those, I will need two 768-byte buffers  (plotSScreen and saveSScreen) and then AppBackUpScreen can hold all sorts of special info about where monsters are, open menus, and all that good stuff. I am planning to insert a 14*64 byte buffer using bcall(_InsertMem) at the end of the program to work as a buffer for the screen instead of using plotSScreen and this should really help with scrolling.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 17, 2013, 03:31:34 pm
Buff(14*64) in Axe should be enough for the buffer you said.
Title: Re: OmniRPG - Coding
Post by: willrandship on February 17, 2013, 04:00:17 pm
Here's a grass animation I made for you. Should be a little less distracting ;)

The normal size version
(http://img.removedfromgame.com/imgs/0-grass.gif)

The blown up version
(http://img.removedfromgame.com/imgs/biggrass.gif)

Not quite was I was trying for, but I think it looks nice.

Here's a 96x64 tiled view (as if it filled the screen)

(http://img.removedfromgame.com/imgs/tilegrass.gif)

I made the grey by drawing it in B/W then applying a 1x1 gaussian blur. Then I posterized it to 4 colors.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 17, 2013, 04:19:09 pm
I'm currently working on a possible battle engine. What did we say already ? In-game, turn-based, or something ?
Title: Re: OmniRPG - Coding
Post by: willrandship on February 17, 2013, 05:24:18 pm
Since you're the one working on it, you get a great deal of sway in that area. I think the consensus was turn-based, due to its simplicity and separation from the map. Being more separate helps in big group projects like this.

Also, a better version of the grass: No black, just the 2 grays and white. It's also more uneven.

(http://img.removedfromgame.com/imgs/1-grass.gif)
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 17, 2013, 06:46:54 pm
Okay, so I go for turn-based. And your grass seems to be nice :)
Title: Re: OmniRPG - Coding
Post by: willrandship on February 17, 2013, 08:08:53 pm
Yeah. I should probably put it in a separate thread, though.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 18, 2013, 02:01:14 am
Right, there's a OmniRPG Sprites thread.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 18, 2013, 06:49:23 am
Bump,

I've made a cool transition, to switch between normal view and battle view. I planned several ones since there will surely be several levels of monsters.

I took a frame of Xeda's gif as the starting map.

(http://mattias.refeyton.fr/espace-ti/omniRPG/transition0.gif)

prgmANIMS is the source (Axe) and prgmBATTLE the executable.

EDIT : broken image, I replaced this one with the new version. It's the same animation but not the same program
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on February 18, 2013, 07:40:49 am
First, that is an awesome transition scene!

As to using Buf(), there may be a problem. Does Axe store the buffer in the program? If so, that will be a waste of 896 bytes because I only need it temporarily.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 18, 2013, 08:01:09 am
Yeah, Buff() is the same as a lot of .db statements. But you can still use an appvar that you can create, use and then delete accordingly to what amount of free RAM you need at a certain moment.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 18, 2013, 10:00:16 am
Moar transitions !

Same as above :
(http://mattias.refeyton.fr/espace-ti/omniRPG/transition0.gif)

Burning image (classic one) :
(http://mattias.refeyton.fr/espace-ti/omniRPG/transition1.gif)

Pixelate and light (you don't see the contrast effect on the screenshot) :
(http://mattias.refeyton.fr/espace-ti/omniRPG/transition2.gif)

Split image :
(http://mattias.refeyton.fr/espace-ti/omniRPG/transition3.gif)

To test, put a number between 0 and 3 in Ans and then run prgmBATTLE with Pic0 in RAM :)
Title: Re: OmniRPG - Coding
Post by: chickendude on February 18, 2013, 10:17:47 am
I love the pixelate animation, but it looks like the screen gets shifted down 8 pixels first...? Anyway, it's super cool.

EDIT: and what do you need the buffer for? If the graph buffer isn't enough i'm sure you can fit whatever you need into saferam (much easier than creating/deleting a variable).
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 18, 2013, 10:20:41 am
It's only due to the pixelate effect I guess (by seeing the code). And thanks :) now I'll carry on with the real battle engine(s ?).
Title: Re: OmniRPG - Coding
Post by: willrandship on February 18, 2013, 01:55:44 pm
Be sure to make it have something special about it. We don't want Yet Another Boring Final Fantasy Clone on our hands.

Those transitions are awesome, by the way!
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 19, 2013, 03:24:24 am
I thank of an isometric view of the battles, where your characters are on the left of a 4*8 isometric platform while enemies are on the right (it involves that battles can't have more than 8 fighters, 4 on each side). For now it looks like this (attached), so I planned your guys to stand on the 4 last cubes (bottom left corner of the pic) and the bad guys to stand on the 4 first (top right corner).

What's your opinion ?
Title: Re: OmniRPG - Coding
Post by: willrandship on February 19, 2013, 03:28:52 am
That sounds pretty cool. Would you be moving in that grid?
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 19, 2013, 03:31:43 am
I don't think so, such small platform is made to have a ground where to stay rather than one where to walk. And in a 4 vs 4 battle, you'd quickly be stuck.

EDIT : on the other hand, it would be cool to have attacks with different ranges : for example, to hit with classic swords or knifes you'll have to be on an adjacent cube, to cast a spell it can depend on the spell, you can throw objects depending on your force etc. For sure it would bring some more elements of gameplay, but I'm not sure it would be very practical.
Title: Re: OmniRPG - Coding
Post by: willrandship on February 19, 2013, 04:18:30 am
I think attacks should be left alone, aside from maybe damage debuffs for the back row. It's nice to have a no-hassle part to the gameplay. AOE stuff would be interesting, and it would depend on the layout you choose beforehand, so pre-battle strategy gets involved somewhat.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on February 19, 2013, 07:36:35 am
That does sound rather cool, matrefeytontias! If I have time later, I was thinking about how some battle animations might work. I don't think it would at all be difficult to make a lightning bolt come from the sky and hit a square or to launch a fireball in an arc and have it pummel a square.
Title: Re: OmniRPG - Coding
Post by: Hayleia on February 19, 2013, 12:39:28 pm
What about a real-time battle engine instead of a turn-based one ? *.*
That would be awesome in my opinion (but certainly a lot harder to do :-\).
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 19, 2013, 12:41:52 pm
Then what would be the point of having several guys in a team ? Real-time is for games with a single character. In turn-based you can have many - and we already discussed it and went for turn-based (which is in fact harder to code due to AI, skills database etc).
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on February 19, 2013, 01:26:24 pm
^Yea, realtime doesn't work as well with a multiparty system unless you have AI controlling the other members. Not nearly as fun IMO.
Title: Re: OmniRPG - Coding
Post by: willrandship on February 19, 2013, 06:16:01 pm
Plus, AI will be insanely difficult, and likely very glitchy. Imagine coding pathfinding X.x
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 19, 2013, 07:25:44 pm
That's why I thank that a turn-based battle-engine without any movements would be clearly enough for a calc game. Moreover, we can still counterpart that with nice animations and stuffs. But writing enemies' AIs will surely be a PITA (which skill use when, on who etc).
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on February 19, 2013, 07:29:06 pm
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.
Title: Re: OmniRPG - Coding
Post by: willrandship on February 19, 2013, 08:15:58 pm
Indeed. Monster AI should be advanced enough to provide a decent challenge, but that's for when we have a working battle engine!
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on February 20, 2013, 07:01:16 am
Yeah, and if we have the monster AI created, we can give the user the option of setting some players to AI. This way new players who don't know what they are doing don't get destroyed early on.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 20, 2013, 08:01:46 am
You mean applying monsters' decisiveness to guys of your team ? That effectively can be a good idea for total newbies.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on February 20, 2013, 08:03:50 am
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.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 20, 2013, 08:11:39 am
Okay then, but let's clear it : I absolutely won't be of any help with the AI ;D I think I'd better work on the battle engine and actions animations.
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on February 20, 2013, 08:16:44 am
Well, IMO I'd probably design the two separately if we chose to allow AI controlled players. Code could possibly be shared between routines, but I'm thinking it would be too much branching if they used the same routines. I could be wrong though. /me is a bit tired at the moment.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on February 20, 2013, 08:19:35 am
For my Samocal RPG it wasn't difficult to make a general AI. In this case, we will need a variable to keep track of which player is attacking and from that we can figure out which players it has to choose from for attacking. If I can find the time, I won't mind trying to work out a decent AI (and I know how to make it learn throughout the battle, too ^_^).
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on February 20, 2013, 08:29:48 am
Also, I planned on coding the whole battle engine as a sole function. But I'll need your opinion on which prototype can be the best. For now I have this :

BeginBattle(playersSequence, enemiesSequence, rewardSequence, canRunAway)

playersSequence : a pointer on a data giving info on who's in the battle, and structured as follows : number of players involved in the battle (1 to 4, one byte), then ID of each player (as many bytes as the first byte of the sequence). Basically, the ID would be used to assign the right stats and sprites to a character.

enemiesSequence : exactly the same as above, but for enemies (involving different stats, sprites etc).

rewardSequence : a pointer to a data giving info about what you obtain after winning the battle, and structured as follows : number of items gained (up to 255, one byte obviously, excluding money, which in my opinion should be given after every battle you win), the amount of money obtained (two bytes, I do think that we should use a 3- or 4-bytes number for the player's money), then each item's ID (as many bytes as the first byte of the sequence).

canRunAway : a simple flag set to allow the flee and reset to forbid it.


What do you think of it ?
Title: Re: OmniRPG - Coding
Post by: Streetwalrus on February 20, 2013, 02:57:19 pm
That's exactly what should be done, IMO. Also, a neat feature would be zone specific effects in the battle (eg weather, local elements, disabling lightning summoning attacks in caves, etc.). ;)
Title: Re: OmniRPG - Coding
Post by: willrandship on February 20, 2013, 04:24:18 pm
A specific boss might deserve its own animation, for example.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on September 10, 2013, 08:22:38 pm
I am not sure who all is in on the coding, except Matrefeytontias and I, but it might be a good idea for me to share what I am doing. For my tilemapper and all of the associated graphics including menus, text, rectangles, and most of the other drawing functions I have, they use a vertically aligned buffer instead of horizontally aligned. This means that instead of the bytes being:
0  1  2  3  4  ...
12 13 14 15 ...
24 25 26 27 ...

I have it as:

0  64 128...
1  65 129...
2  66 130...
3  67 131...
.........

I am using this method because it is working a lot faster and the code is smaller (it's also easier, actually). Axe uses the former method, and I know there will be a bunch of Axe coding for this project. Because of this, I think the tilemap stuff should be vertically aligned and everything else can be horizontally aligned to make Axe coding easier. As an alternative, I can create graphics routines callable from the Axe programs that work with vertically aligned buffers.

Since I will probably be the one delegated to tilemap stuff, which functions should I create? I was thinking that the following commands might work:

LoadMap(basename,mapID). basename would be something like OMAP and the ID would be two bytes identifying the map number. This command would load all of the appropriate data and pointers required to actually draw the map.

MoveLeft() This would scroll the map right if the player is able to move to the tile to the left. Return the value of the tile currently being occupied, the tile.
MoveRight()
MoveUp()
MoveDown()
TileSel() returns the tile value that the player is facing. For example, if the player presses Enter or 2nd, this might be called to see if the tile is anything useful.
AddEvent()
DelEvent()

These would be routines that the Axe code would make a call to to update tilemap stuff. The tilemap I have is running from an interrupt, by the way. I found it to be very useful for updating animations at a fairly constant rate.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 11, 2013, 12:43:33 am
I think that each of these functions are required :P btw you should make them an axiom, because then Axe will can interface with it. If we happen to have too much subroutines for a regular ASM program, we can use my PageSwap axiom to load functions from an app.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on September 13, 2013, 08:18:55 am
Okay, I have a few other things to discuss about some code that I have from previous projects:

Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 13, 2013, 09:36:21 am
We can't do anything with that, all ASM code must be Axe-friendly.
Title: Re: OmniRPG - Coding
Post by: Eiyeron on September 13, 2013, 12:13:52 pm
FOr the Battle engine, I making one. I'll sure need help, but when done, you'll have a powerful and beautiful engine!
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on September 13, 2013, 12:22:25 pm
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 :
Code: [Select]
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:
Code: [Select]
Str1Asm(CD8640)
(again, the adress will likely be changed).
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 13, 2013, 12:29:16 pm
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 ?

@Xeda112358 : for now I don't really see why we would need any of the rect routines since Axe already has everything we need. A specific text routine to display text in a dialog box with a character pic next to it would be nice IMO :)
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on September 13, 2013, 12:48:39 pm
Oh, the routines for all of the graphics in the app use a vertically aligned buffer, whereas Axe uses horizontally aligned. I do this for speed and memory, but this means that in order to draw text on the screen when the map is in view, or do any drawing on screen, you won't be able to use the Axe routines. This won't be the case for the battle engine stuff, though, unless you all would like to use vertically aligned buffers for battle animations and whatnot.

See this post (http://ourl.ca/17704/360480) above for a description of what vertically aligned buffers are.

@Matrefeytontias and other assembly programmers: Using this method, drawing a tile is as easy as:
Code: [Select]
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.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 13, 2013, 01:12:12 pm
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.x
Title: Re: OmniRPG - Coding
Post by: Eiyeron on September 13, 2013, 01:16:37 pm
My engine won't be finished before a long moment because it(s quite different from a typical turn based RPG battle, and needs to cope with the overworld thing (for in world hp loss for instance). Which kind of engine do you needs? Action? Turn based?
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 13, 2013, 01:21:56 pm
IIRC we went for turn-based, thus simplifying AI coding and allowing for nice attacks animations :w00t:

I planned to keep the idea I explained in this post (http://ourl.ca/17704/338984), is it still okay ?
Title: Re: OmniRPG - Coding
Post by: Eiyeron on September 13, 2013, 01:36:56 pm
I have the idea to use real time hp/pp rolling meters. THey are constantly increasing/decreasing if the target doesn't match the currrent P. THus, mortal damage could be avoided.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 13, 2013, 01:45:23 pm
I don't understand what you mean .__.
Title: Re: OmniRPG - Coding
Post by: Eiyeron on September 13, 2013, 01:47:09 pm
THat engine (http://ourl.ca/19406)
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 13, 2013, 02:07:55 pm
Oh so you mean real-time battle ? I don't think this type of battle engines fits a calculator game ...
Title: Re: OmniRPG - Coding
Post by: Eiyeron on September 13, 2013, 02:53:21 pm
Not real time. Turncbased, but life is constantly flowing.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 13, 2013, 03:36:01 pm
That would require the use of states flags I guess ? Which will have an effect during the whole battle ?
Title: Re: OmniRPG - Coding
Post by: Eiyeron on September 13, 2013, 04:08:41 pm
Mainly HP. PP is too low to have a real impact. If you take more damage than your life, your life meter will ocnstantly go down, but you still can heal yourself and avoid death iuntil the rolling meter rolls down to 0.

The main flag is to detect if someone fall down during an action, and change the turn flow, like channeling the heal to someone else, or invalidate the action, even after the action animation.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 13, 2013, 04:18:40 pm
I still find that a bit overkill ... A turn-based system à la FFTA seems good to me though.
Title: Re: OmniRPG - Coding
Post by: Eiyeron on September 13, 2013, 04:46:08 pm
Meh. If you'll play Mother 3, you'll start to love it.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on September 14, 2013, 11:06:05 am
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.x
I have line, circle, rectangle, pixel, sprite (clipped), tile, text, menu, LCD updating, grayscale, tilemap. Anything else?

EDIT: Also, the battle engine itself could use horizontal buffers, too, so that pure Axe could be used. I could also make a routine to convert a vertical buffer to a horizontal buffer or vice versa, and I could make an LCD update that works with both types of buffers.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 14, 2013, 11:11:03 am
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.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on September 14, 2013, 11:28:52 am
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.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 14, 2013, 11:44:55 am
It's the case, battles have their own terrain, but then since it permits the use of horizontal buffers, we'll use Axe's graphical commands and the tilemap will use yours, so the final program will include two versions of the same routine, one for each buffer alignment, which is a huge waste of space.
Thus, we need to choose one buffer alignment that will be used for the whole game, else we'll end up wasting hundreds of bytes writing routines to handle both alignments.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on September 14, 2013, 11:58:54 am
Ah, that is true. I have been optimising for speed, so currently, all of the 'duplicated' graphics routines take 979 bytes. It is doubling the graphics speed while keeping it running smoothly, too.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 14, 2013, 12:13:31 pm
So the best solution would be to build an axiom with a vertically-aligned version of Axe's graphical routines, and use this axiom instead of all Axe's functions. Also, direct plotSScreen access will need to be done differently.
Title: Re: OmniRPG - Coding
Post by: Eiyeron on September 14, 2013, 01:49:27 pm
I don't really understand the main advantages to use vertically aligned data. What could it improve?
Title: Re: OmniRPG - Coding
Post by: chickendude on September 14, 2013, 02:19:17 pm
Faster and smaller code, apparently. ;)
Title: Re: OmniRPG - Coding
Post by: willrandship on September 14, 2013, 03:12:32 pm
How frequently would the switch between buffer styles be made? If it's once every few minutes or so, we have room in the archive.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 14, 2013, 03:41:09 pm
Again, think about 83+ BE users (like me). I currently have about 23KB of free flash, although I have no other app than Axe and Mimas (and IkarugaX + source, the total being around 35KB. That's why I'm currently finishing it in high-speed mode before starting anything else to free flash).
Vertically-aligned buffers allow for faster drawing, but I guess TI didn't use them because what you see on-screen doesn't correspond to how memory is arranged.
Title: Re: OmniRPG - Coding
Post by: chickendude on September 14, 2013, 04:53:34 pm
But.. why would you need different buffers? You can use the same 768 bytes for both. When running the battle engine you won't be running the tilemap engine, you can use the same space for both.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 14, 2013, 04:56:55 pm
You don't seem to understand. It's the same buffer that is used, but it's used in different ways. And since each way requires a specific routines set, we'll have to go for only one style to save space.
Title: Re: OmniRPG - Coding
Post by: willrandship on September 14, 2013, 05:17:08 pm
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.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 14, 2013, 05:41:04 pm
I will never work on a game I won't be able to play. And since "OmniRPG" means that it's the game by pretty much THE TI community, it'd be stupid to say to some members "well, we don't feel like trying to optimise, so go find another game".
Title: Re: OmniRPG - Coding
Post by: willrandship on September 14, 2013, 06:15:00 pm
This isn't a case of "Not Trying to Optimize". This is a case of "Trying to optimize a certain way, that removes 83+BE support."
Title: Re: OmniRPG - Coding
Post by: Streetwalrus on September 14, 2013, 06:31:06 pm
Well dropping BE support means Matref is out, and we don't want Matref out because he's and awesome coder. I guess the mapping engine has very few graphics routines anyway so it shouldn't impact size too much. ;)
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 14, 2013, 06:51:03 pm
@willrandship putting Return!If Full at the beginning of a program is not called optimizing. It's called being lazy.

@StreetWalker thanks ^^ and for tilemaps, remember that there will also be regular sprites and other things ; but you'll have to ask Xeda for that rather than me.

Also, I got a skeleton of battle engine done. For now, it's able to :
The whole engine is packed into a single function that takes 3 arguments. For example, here's the command I use atm :

BeginBattle(Data(4,0,1,2,3),Data(2,3,2),Data(3,0,2,1,1000r))

What does it do : it tells the engine to start a battle which will involve 4 party members (0 to 3), 2 enemies (3 and 2) and that winning the battle will give the player 3 items (1, 3 and 2) and 1000 dollars/coins/insert_some_name_for_money_here.

I'll post a screenshot ASAP so you'll see it in action :)
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on September 14, 2013, 08:53:49 pm
I would like to point out that regardless of the routine set used, a tilemap engine would still have to be written, and using vertically aligned buffers makes the code significantly smaller. If I converted it to use horizontally aligned buffers, the code size would increase. I also feel that we should be working toward keeping this at 6MHz and low size. I think that the whole battle engine, tilemap engine, and all of the other engines could easily fit on one app page, allowing the data to be external.
Title: Re: OmniRPG - Coding
Post by: Roboman on September 14, 2013, 10:17:24 pm
Even if we can't keep it at 6MHz, we will end up with a pretty fast program running at 15 MHz :)
So, it's a nice goal either way :thumbsup:
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 15, 2013, 01:45:44 am
@Xeda112358 yep, totally agree.

@Roboman if we can't keep it at 6 MHz, I won't be able to play it with my sole TI-83+ BE, so I'll just stop working on it.

Also, here's the promised screenshot :D Even if we don't see much things happen, everything on-screen has been generated by an algorithm (excepting sprites of course) :

(http://img.ourl.ca//battleEngine1.gif)

The current call to BeginBattle is :

BeginBattle(Data(4,0,1,2,3),Data(2,3,2),Data(3,0,2,1,1000r))
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on September 15, 2013, 11:20:12 am
Wow Matrefeytontias, that looks like it will be pretty cool! I can't wait to see some battle animations! o.o I already have ideas of what it will look like.
Title: Re: OmniRPG - Coding
Post by: Sorunome on September 15, 2013, 12:05:57 pm
wow, that is looking awesome O.O
You are sure good with 3D stuff :)
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 15, 2013, 01:20:56 pm
What I planned for data format is something like classes. Here's what I mean :That's how I see the thing. What do you think of it ?
Title: Re: OmniRPG - Coding
Post by: Streetwalrus on September 15, 2013, 03:18:38 pm
Sounds good to me !
Title: Re: OmniRPG - Coding
Post by: Eiyeron on September 15, 2013, 04:41:39 pm
It's almoqt like every rpgs I olayed and dissecated the engine! ;) It should rock!
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 15, 2013, 04:45:22 pm
We should arrange all datas like that then :) I'll make sure to make a small test with that data format in my engine.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on September 15, 2013, 06:14:01 pm
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.

EDIT: Otherwise, it looks good :) Maybe the last two bullets could get merged, then...
Title: Re: OmniRPG - Coding
Post by: tr1p1ea on September 15, 2013, 06:19:35 pm
Yeah i agree, you shouldnt limit yourself to sprites. Perhaps you can have a small data structure that can be parsed when drawing animations which can reference sprites, lines, ASCII (or a combination) for its frames.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 15, 2013, 07:13:25 pm
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 :
Data(Str1r,5,0,300r,255,0,LAttackr)

And you would write :

:"Thunderbolt"->Str1
:
:etc
:
:Lbl Attack
:animation code for Thunderbolt here
Title: Re: OmniRPG - Coding
Post by: willrandship on September 15, 2013, 07:47:29 pm
That's not what you said, though.
Quote from: Matrefeytontias
At last, there's the animation. It has a number of frames, and as many sprites as the number of frames.
Title: Re: OmniRPG - Coding
Post by: Matrefeytontias on September 16, 2013, 12:36:47 am
Here we're talking about attack animation, not regular animation. The double use of "animation" confused everybody I guess ;D
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on September 16, 2013, 05:51:25 am
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.

True, but I always suggest games work for as many models as possible. Besides, if you are creating a great game people besides Omnimagicans will likely be playing it. :) The TI-83+ is still the cheapest available model TI-supports. Not to mention how many old used models are running around.
Title: Re: OmniRPG - Coding
Post by: chickendude on September 16, 2013, 10:56:24 am
Personally i don't think grayscale is worth dropping 83+ support. Sometimes it looks nice, but in general i think B/W looks much better.
Title: Re: OmniRPG - Coding
Post by: pimathbrainiac on September 16, 2013, 01:57:36 pm
I think that grayscale should be a yes, heck, even interrupt gray. Just not GRAYLIB interrupt gray, ya know, because ti-83 support.
Title: Re: OmniRPG - Coding
Post by: Streetwalrus on September 16, 2013, 02:00:51 pm
Maybe it could be made optional. ;)
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on September 16, 2013, 03:07:10 pm
I think that for users that have 15MHz models, they should be able to toggle 15MHz/6MHz, and we could add in grayscale as an option to toggle. If we do 3-level grayscale, it will be a lot easier to make drawing routines that can be toggled between grayscale and b/w. However, I do think b/w is the best option and the most memory friendly. Scrolling a grayscale tilemap would be quite a bit slower (though I might save some speed by combining the LCD update and screen shifts).
Title: Re: OmniRPG - Coding
Post by: TIfanx1999 on September 16, 2013, 03:16:04 pm
I thought programming wise, there was no difference between 3 and 4 level gray. I'd suggest keeping grayscale in if possible.
Title: Re: OmniRPG - Coding
Post by: Streetwalrus on September 16, 2013, 03:25:35 pm
I'd say that it should be optional and that we can easily generate a stripped resource file with spasm. Also 4 level is a bit different from 3. We should keep 3 though because it won't require different sprite sets for b/w.
Title: Re: OmniRPG - Coding
Post by: Xeda112358 on September 16, 2013, 03:38:08 pm
In Grammer, I use only one LCD updating routine and it does 2 level, 3 level, and 4 level grayscale because it is technically a 4-level gray routine, using different saturation levels of buffers. However, I think that if we use 3 level grayscale and monochrome as two options, then switching between them is as easy as turning the gray layer on or off and changing the frequency at which the LCD is updated. (Images look a lot better when going from 3 level to monochrome, in my opinion, as opposed to 4 level to monochrome.)

Again, from a graphics perspective, handling the menus might become a pain, but could be manageable. As well, twice the amount of drawing would have to be done, but that can probably be handled without too much of a slow down, even for 6MHz. My real concern is memory and how much of it will be needed. But all this can probably be figured out :)
Title: Re: OmniRPG - Coding
Post by: Hayleia on September 16, 2013, 03:41:57 pm
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).

-In 3 lvl "mode", you basically have a black buffer and a grey buffer. Any "pixel" on the black buffer will be black on screen, and any "pixel" on the grey buffer will be grey on screen (except if it is black on the black buffer). Both buffers are quite independent, you can for example scroll the grey buffer without the black buffer having change in any way, so the grey moved on screen and the black stayed where it was, or the contrary, move something black without touching the grey.

-In 4 lvl "mode", that is different, because then with two bits you have exactly enough bits to make 4 numbers (so 4 shades). You now have a light grey buffer and a dark grey buffer. So you guess how to make white, light grey and dark grey. But then you have a problem with black: black is basically light_grey+dark_grey. So moving a buffer will move the shade of grey it is associated to, but it will also have an effect on black.

(at least, that is how it works in Axe, except if I am mistaken and if I made all my grey by luck in my programs).
Title: Re: OmniRPG - Coding
Post by: Streetwalrus on September 16, 2013, 04:01:25 pm
That's how it works in Axe yes. However you can also make 3 level gray by quickly alternating between two buffers or 4 by having a 2:1 time ratio for displaying them. Though in the case of three both buffers must be black for the screen to be black.
Title: Re: OmniRPG - Coding
Post by: willrandship on September 16, 2013, 05:04:04 pm
A problem with choices for grey/not grey is the lack of space. Greyscale sprites don't look so good when you just use them as B/W sprites, so odds are you'll need a whole new set of sprites for each option.

If it's an option, it should be a different version to download. That way, the extra data won't be there (one of the bigger issues for BE models anyway)