You do realize you are going to obscene lengths with this project?
I just keep having random ‘what do real games do’ thoughts, then I test them 
4 Likes
Is that a bad thing?
1 Like
Added alpha blending to the menu, so it looks a little nicer. It’s currently getting around 18fps on hardware with the menu showing, that’s not bad.
For future reference, My audio routine doesn’t play nice with LibAudio and the following change might be needed in order to reuse the 32bit timer…
PokittoHWSink.hpp
public:
void init(){
if(this->wasInit)
return;
this->wasInit = true;
// only init the timer if not setup already
NVIC_SetVector((IRQn_Type)TIMER_32_0_IRQn, (uint32_t)IRQ);
4 Likes
Small update, managed to get the background scenery to stream also, so the only part of the level data that is stored in flash is the palette and tiles. Meaning I can technically have a 65535x65535 tile level as long as I keep the tile count to about 800 or less.
7 Likes
Just gave a ‘tall’ level a try, it seems my math is wrong for calculating the scenery offset…
6 Likes
Joe goes to Piedup! One of my favorite NES games.
1 Like
Took me years tom complete WWIII, had to use an emulator with save states in the end, I just couldn’t sit and play long enough at a single time without saving.
1 Like
Tiny little bit of work in the background, got a solid 26fps, not bad.
But with a lot of vertical lines in this level, I’m seeing a lot of tearing on the emulator AND hardware. I don’t think that the Pokitto screen has any sort of feedback for v-sync or h-sync, does anyone have any idea about reducing the tearing at all?
d
1 Like
I was told that there were no v-sync/h-sync at all because the necessary wires aren’t here at all.
It seems the only way of reducing tearing is not scrolling at all unfortunately …
1 Like
Interlacing?
1 Like
From my initial tests with PtaD’s engine I discovered that the tearing is worse when moving around quickly, but barely noticeable otherwise. Also the faster your lineFillers are the faster the entire screen will refresh which reduces the noticeable tearing. Without a v-sync tearing is pretty much unavoidable though, you can only reduce it a bit.
I don’t know if you guys understood my comment on interlacing. You could try updating odd/even rows on every second update.
Afterall, thats how analog TV worked
1 Like
Only problem there is that you would send a command to the screen then pump all lines, but with interlacing every line would also have to send the command to change the vram pointer. Unless the display has a built in interlacing mode.
Hard to say without proper testing though if the tradeoff would be worth it.
I did tried interlacing as a way to increase the FPS, and it kind of rendered weirdly. It’s a nice effect if you want it tho, kind of “glassy”. Basically it replaces tearing with another artifact on the HW
A GIF of ARIAT with interlacing, done last November
2 Likes
To be fair the interlacing artifacts did help improve that explosion effect.
2 Likes
In my own experience with the emulator, for games that use scrolling, you’ll need to increase framerate to at least 40 fps in order to reduce tearing to an acceptable level. Only v-sync or hw double buffer would remove tearing entirely.
2 Likes
If that worked, I would have thought it would be reasonably cheap.
Though there are ways around having adjust the vram address.
Analogue TV used to be interlaced, and sometimes if you play interlaced video on a digital video player you end up with that same effect.
Just do an image search for ‘deinterlacing’ and you’ll get a good handful of examples.
Interlacing would mean using half a full frame buffer worth of memory to buffer every other line,
so it might be too expensive depending on how much memory is available.
However, the tearing effect could possibly be removed by only updating the gameplay every other frame or by double buffering the entire game state, so the logic is updated every frame, but every even frame draws the previous state instead of attempting to draw the current state (which should avoid input lag, but will probably still result in jerky visuals).
Whether or not either of those are practical will depend on what the game’s actually doing - how much memory it needs for the world & entities, and how CPU intensive each update is.
That’s pretty much what I did for ARIAT. I used a modified version of TAS to implement the interlacing - instead of just uploading the “skipped” lines, this TAS would jump the DRAM to the next “rendered” line.
And it did boost FPS! But really I wasn’t fond of the effect, it’s worse than tearing for me. Could be good for cinematics tho, or if I was a better artist / animator I guess
Maybe that’s what you wanted to say, but double buffer would work only if it’s implemented where it’s needed - and here, it’s inside the LCD (what @SkyBerron refers as “hw double buffer”). Double buffering the game state wouldn’t solve anything, unfortunately, since the issue isn’t here (game state double buffering does have its uses tho, when you have a Renderer who is on another thread)
I did try interlacing a while back, I remember not being happy with it at the time, but I deleted the code and I’m struggling to get it working again.
Is hw double buffering possible? I think I read that there should be enough RAM on the screen, but from what I remember from a couple of years ago, you can only write to visible areas??
[edit[
No, no, no, no, no, no, no, bad idea…
4 Likes