Author Topic: OmniRPG - Coding  (Read 67039 times)

0 Members and 1 Guest are viewing this topic.

Offline Eiyeron

  • Urist McEiyolobster
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1430
  • Rating: +130/-10
  • (-_(//));
    • View Profile
    • Rétro-Actif : Rétro/Prog/Blog
Re: OmniRPG - Coding
« Reply #225 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?

Offline chickendude

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 817
  • Rating: +90/-1
  • Pro-Riot Squad
    • View Profile
Re: OmniRPG - Coding
« Reply #226 on: September 14, 2013, 02:19:17 pm »
Faster and smaller code, apparently. ;)

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

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

Offline chickendude

  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 817
  • Rating: +90/-1
  • Pro-Riot Squad
    • View Profile
Re: OmniRPG - Coding
« Reply #229 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.

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

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

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 #232 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".

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 #233 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."

Offline Streetwalrus

  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3821
  • Rating: +80/-8
    • View Profile
Re: OmniRPG - Coding
« Reply #234 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. ;)

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 #235 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 :
  • Display the battle scene on a 4*4 isometric 3D grid (no textures yet, 16*16 blocks)
  • Place correctly the party members and enemies on the corresponding blocks of the map, depending on the number of characters involved in the battle
  • Display participants using dynamic sprites
  • Display with text the name of items and the amount of money that the player obtained by beating all opponents (pressing [clear] is the only way to beat all opponents atm :P)

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 :)
« Last Edit: September 15, 2013, 01:47:01 am by Matrefeytontias »

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

Offline Roboman

  • LV3 Member (Next: 100)
  • ***
  • Posts: 96
  • Rating: +10/-2
  • These peanuts taste so good!
    • View Profile
Re: OmniRPG - Coding
« Reply #237 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:
:w00t:
UP-UP-DOWN-DOWN-LEFT-RIGHT-LEFT-RIGHT-B-A-ENTER


I always post in good faith!
http://en.wikipedia.org/wiki/Good_faith
If I end up being rude please tell me and understand!
Spoiler For Spoiler:
:-[  I never mean to say things ... negativley...
I am a bit socialy aqward so I often dont pick up on sarcasm or recognize myself being rude...

...

I am sorry for any offence...

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 #238 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) :



The current call to BeginBattle is :

BeginBattle(Data(4,0,1,2,3),Data(2,3,2),Data(3,0,2,1,1000r))
« Last Edit: September 15, 2013, 01:46:51 am by Matrefeytontias »

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