Re: [hatari-devel] 2 more falcon programs running better : Pinball dream and Killing impact

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]



> No, it breaks Doug's Bad Mood game 3D rendering.


That's logical, because Doug's HUD is at bottom of the screen (whereas Pinball dreams HUD is at top of the screen and the main part of the pinball is after, and Killing impact does write to the counter only once per VBL, so no screen breaking).

I'll test it too, thanks to point it to me.


> I think cleanly implemented hacks that are clearly
> marked in code with TODO comments and listed in
> doc/todo.txt are fine, if they don't break things.


OK, good. I'll try to find the best way to implement it.


> In any case it should wait after bug fix release.

Full agree here. This has been wrong for ages, it can wait a bit more to do it cleanly.

Regards

Laurent


Le 20/12/2020 à 01:24, Eero Tamminen a écrit :
Hi,

On 12/20/20 1:16 AM, Laurent Sallafranque wrote:
I post here my current search for sharing with you.

I've worked on a memory address that is not used by the videl for now : the videl address counter.

At least, 2 programs write into it : killing impact and pinball dreams.

By adding only 3 lines of code into videl.c, I manage to remove (partially for now) the screen garbage for these 2 programs.

Now, the screens are correctly rendered and the games are playable.
>
With killing impact, there's another problem with vertical display (I think the screen may be doubled on real Falcon ?)


With Pinball Dreams, the game change twice the counter address : 1st time for score display and 2nd time for the game itself (that's why there's still garbage at bottom of the table now, the screen  should be displayed lower (the upper part of the screen should display the score panel).

For now, you can consider it as a proof of concept.

It renders better the 2 games,

Verified.


but that's not perfect.

No, it breaks Doug's Bad Mood game 3D rendering.

That shows just garbage (area above that renders
fine).


And when you quit the games, the hack still operate, but it should not.

The good way to solve it would be to improve thye videl

The bad way (but with a good result) would just consist to add a new variable to videl, reset it to 0 at the brginning of a VBL and if a program changes the counter, set this variable to 1. like this, the hack would work cleanly.

Should I complete the temporary hack (for better rendering but not perfect) or shouldn't be add such a bad hack that may be hard to understand later is someone works on videl later (except if we add a ton of comments to explain it).

I think cleanly implemented hacks that are clearly
marked in code with TODO comments and listed in
doc/todo.txt are fine, if they don't break things.


In any case it should wait after bug fix release.


    - Eero

I'm interrested in your point of view.

Regards

Laurent


The proof of concept patch : diff -u

diff --git a/src/falcon/videl.c b/src/falcon/videl.c
index cf5ce874..e4019413 100644
--- a/src/falcon/videl.c
+++ b/src/falcon/videl.c
@@ -942,6 +942,10 @@ bool VIDEL_renderScreen(void)
         bool change = false;

         Uint32 videoBase = VIDEL_getVideoramAddress();
+       Uint32 videocounter = (IoMem_ReadByte(0xff8205)<<16) + (IoMem_ReadByte(0xff8207)<<8) + IoMem_ReadByte(0xff8209);
+
+       if (videocounter != 0)
+               videoBase = videocounter;

         if (vw > 0 && vw != videl.save_scrWidth) {
                 LOG_TRACE(TRACE_VIDEL, "Videl : width change from %d to %d\n", videl.save_scrWidth, vw);








Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/