Join us on Discord!
You can help CodeWalrus stay online by donating here.

WalrusRPG - a cross-platform J-RPG engine

Started by novenary, November 17, 2014, 07:00:20 PM

Previous topic - Next topic

0 Members and 7 Guests are viewing this topic.

Dream of Omnimaga

#30
30 fps doesn't seem too bad actually for a calc. But yeah if it drops at like 15 fps it could annoy some players. 20-24 would probably be fine for everyone or at least tolerated by Call of Duty and Crysis fans. A lot of people can't even run recent computer games above 20 FPS at minimum settings anyway.


EDIT: In fact I heard once that it's under 12 FPS that a video really starts to get unwatchable. Of course for action games that would affect gameplay but for an RPG, if people are fine with watching choppy Youtube videos with horrible compression, then I don't see why they should have a problem with even 12 FPS in a tilemapped turn-based RPG.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Duke "Tape" Eiyeron

30 fps? Butdoes nkaruga runs smoother than that? I feel we're getting a similar problem than the Prizm.
  • Calculators owned: A lot.

novenary

Well, I spent quite some time reducing CPU load from hungry sources. For example n2dlib uses buffer copying which is incredibly inefficient when you redraw the whole screen every frame like I do, so my graphics module implements buffer swapping. I should probably learn how to use interrupts to avoid stalling the whole thing when doing vsync (which I also implemented myself as n2dlib doesn't do it). I also enabled -Ofast compiler optimizations right from the start (when I realized that I still had -Os in my Makefile that is), so that we get an executable that runs as efficiently as possible and to avoid having to deal with a cload of bugs if we were to enable it later than now.
The map renderer is still not complete as we need 3 layers + object and NPC rendering to accurately reproduce the Pokémon gen-III mapper. This is the kind of stuff that will definitely slow down rendering so I'll see what I can do about it. Since I redraw the whole screen, animated tiles are basically free. :)
We're very likely to recommend overclocking for this game although it won't be necessary (just so that the framerate stays smooth, I develop on my calc running at 246MHz and aeTIos's runs at 252).
The problem we have is not refreshing the whole buffer every time but handling a huge amount of sprites (we draw a 15x11 chunk of the map, with some tiles being multi layer and NPCs, the character, weather effects... that's about 400 sprites every frame under spike load).

Duke "Tape" Eiyeron

That's pretty hardcore. Why not storing static parts a bigger bitmap? It would decrease the blit overhead at the trade of memory.
  • Calculators owned: A lot.

novenary

Believe me, we already considered it. That alone is one of the reasons why we dropped monochrome models. They don't have nearly enough RAM for that. Maybe if we were to tell the os to c off and force a reset on exit then we could program the calc down to the metal. But that would be too much of a pain. Also consider that a 100x100 map prerendered as bitmap would use about 11MB of RAM while we could use it for something else (iirc there's ~4MB free on the classic, +32MB on the CX). And that's without animated tiles. While it would drop about 200 to 300 sprites per frame, this is a massive tradeoff that will only be accepted if it's absolutely necessary and it actually fits in RAM (we might have to use the aforementioned hack to use the full 64MB sdram that the CX sports).
As you can see these measures are pretty extreme so let's do our best to avoid them. Should allow the game to run at 60fps though. :P

Dream of Omnimaga

Oh wow I didn't realize you needed three mappers O.O. Now that explains why it won't be as fast. I was thinking with 1 layer plus some sprites in mind at first. On the other hand, the extra effects and stuff will definitively spice the game up. :)

Good luck!
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

novenary

Well I could take some other shortcuts to speed up the mapper like caching layered tiles and weather effects which will use way less RAM and get me to about 200 sprites per frame (that's giving myself a lot of headroom - if we reach 175 then it means there's a cload of NPCs lol).

Duke "Tape" Eiyeron

110 * 110. But even the DS loaded smaller maps than that! Just load map chunks, that'll (maybe) less heavy on the ram, won't it be?
  • Calculators owned: A lot.

aetios

We could render the back layer at runtime and shift it, but I have no idea how any of that works in C.
ceci n'est pas une signature

Dream of Omnimaga

Loading the entire map to avoid having to render it in real time would definitively help, but that requires a crapload of RAM during execution, which could cause some problems for people who got a lot of ROMs and mViewer stuff on their calc.
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

novenary

Eiyeron that could work, I'm taking note here.
aeTIos : We need to prerender all three layers at the same time, x4 or so because of animations, not because of multiple layers. As for shifting around the picture, it's really simple.
DJ : I don't see how having many files would cause any problems. The filesystem is in flash after all.

Dream of Omnimaga

Oh wait I forgot that on the Nspire, executable files aren't stored in RAM. I know the OS is copied to RAM on boot or something but I forgot that it was different for the documents.

But yeah, if a map is 128x128 tiles and you pre-render it, then you need like 38 MB of RAM assuming it's 16-bit and 19 if it's 8.  Even moreso if you have three layers (in such case you won't even have enough free RAM if the three images are 16 bits.)
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

novenary

the layers just render to the same buffer. It would be silly to render them separately.

Duke "Tape" Eiyeron

Blit all the subblitals? Maybe the most unefficientvway of doing it z unless some animations spend on only one layer...
  • Calculators owned: A lot.

novenary

I didn't really understand that post. :P

Powered by EzPortal