Author Topic: OmniRPG - Coding  (Read 67186 times)

0 Members and 2 Guests are viewing this topic.

Offline stevon8ter

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 663
  • Rating: +10/-0
    • View Profile
Re: OmniRPG - Coding
« Reply #15 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
None of my posts are meant offending... I you feel hurt by one of my posts, tell me ... So i can appoligise me and/or explain why i posted it


Hi there, I'm the allmighty (read as: stupid, weak...) STEVON8TER

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: OmniRPG - Coding
« Reply #16 on: December 06, 2012, 05:17:17 pm »
Hehe, the pressure is on XD

Offline willrandship

  • Omnimagus of the Multi-Base.
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2953
  • Rating: +98/-13
  • Insert sugar to begin programming subroutine.
    • View Profile
Re: OmniRPG - Coding
« Reply #17 on: December 06, 2012, 07:34:21 pm »
Sounds exciting! 16x16 is big, but it does give a lot more freedom with graphics.

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: OmniRPG - Coding
« Reply #18 on: December 07, 2012, 08:05:51 am »
I was looking at Slova 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

Offline stevon8ter

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 663
  • Rating: +10/-0
    • View Profile
Re: OmniRPG - Coding
« Reply #19 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
None of my posts are meant offending... I you feel hurt by one of my posts, tell me ... So i can appoligise me and/or explain why i posted it


Hi there, I'm the allmighty (read as: stupid, weak...) STEVON8TER

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: OmniRPG - Coding
« Reply #20 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 ._.

Offline stevon8ter

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 663
  • Rating: +10/-0
    • View Profile
Re: OmniRPG - Coding
« Reply #21 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
None of my posts are meant offending... I you feel hurt by one of my posts, tell me ... So i can appoligise me and/or explain why i posted it


Hi there, I'm the allmighty (read as: stupid, weak...) STEVON8TER

Offline Xeda112358

  • they/them
  • Moderator
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4704
  • Rating: +719/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: OmniRPG - Coding
« Reply #22 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.

Offline squidgetx

  • Food.
  • CoT Emeritus
  • LV10 31337 u53r (Next: 2000)
  • *
  • Posts: 1881
  • Rating: +503/-17
  • rawr.
    • View Profile
Re: OmniRPG - Coding
« Reply #23 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
« Last Edit: December 07, 2012, 10:16:57 am by squidgetx »

Offline aeTIos

  • Nonbinary computing specialist
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3915
  • Rating: +184/-32
    • View Profile
    • wank.party
Re: OmniRPG - Coding
« Reply #24 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)
I'm not a nerd but I pretend:

Offline Yeong

  • Not a bridge
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3739
  • Rating: +278/-12
  • Survivor of Apocalypse
    • View Profile
Re: OmniRPG - Coding
« Reply #25 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
Sig wipe!

Offline squidgetx

  • Food.
  • CoT Emeritus
  • LV10 31337 u53r (Next: 2000)
  • *
  • Posts: 1881
  • Rating: +503/-17
  • rawr.
    • View Profile
Re: OmniRPG - Coding
« Reply #26 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
« Last Edit: December 07, 2012, 10:39:29 am by squidgetx »

Offline TIfanx1999

  • ಠ_ಠ ( ͡° ͜ʖ ͡°)
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 6173
  • Rating: +191/-9
    • View Profile
Re: OmniRPG - Coding
« Reply #27 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.

Offline tr1p1ea

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 647
  • Rating: +110/-0
    • View Profile
Re: OmniRPG - Coding
« Reply #28 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.
"My world is Black & White. But if I blink fast enough, I see it in Grayscale."


Offline Sorunome

  • Fox Fox Fox Fox Fox Fox Fox!
  • Support Staff
  • LV13 Extreme Addict (Next: 9001)
  • *************
  • Posts: 7920
  • Rating: +374/-13
  • Derpy Hooves
    • View Profile
    • My website! (You might lose the game)
Re: OmniRPG - Coding
« Reply #29 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

THE GAME
Also, check out my website
If OmnomIRC is screwed up, blame me!
Click here to give me an internet!