Author Topic: OmniRPG - Coding  (Read 66072 times)

0 Members and 1 Guest are viewing this topic.

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 #135 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?

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: OmniRPG - Coding
« Reply #136 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}.

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 #137 on: December 12, 2012, 11:15:39 am »
Oh, I see it now :D I didn't see the 4-cycle tiles. Nice! :D

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 #138 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 .__.)

Offline stevon8ter

  • LV7 Elite (Next: 700)
  • *******
  • Posts: 663
  • Rating: +10/-0
    • View Profile
Re: OmniRPG - Coding
« Reply #139 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,...
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 #140 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).

Offline TIfanx1999

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

Offline Matrefeytontias

  • Axe roxxor (kinda)
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1982
  • Rating: +310/-12
  • Axe roxxor
    • View Profile
    • RMV Pixel Engineers
Re: OmniRPG - Coding
« Reply #142 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.

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 #143 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.

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 #144 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).

Offline tr1p1ea

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


Offline TIfanx1999

  • ಠ_ಠ ( ͡° ͜ʖ ͡°)
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 6173
  • Rating: +191/-9
    • View Profile
Re: OmniRPG - Coding
« Reply #146 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. :)
« Last Edit: December 15, 2012, 09:27:02 am by Art_of_camelot »

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 #147 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

Offline TIfanx1999

  • ಠ_ಠ ( ͡° ͜ʖ ͡°)
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 6173
  • Rating: +191/-9
    • View Profile
Re: OmniRPG - Coding
« Reply #148 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. :)
« Last Edit: December 15, 2012, 09:27:26 am by Art_of_camelot »

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 #149 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.