Window refresh problems under Geneva/Neodesk

[tschak909]

Sorry, Not feasible, since I am drawing color. Also, I _REFUSE_ to add a barrier to entry for users. It's hard enough for them to get a wifi modem (or in the case when I get STiNG support in, a network card) and to set it up.

I am taking another crack at implementing a redraw queue.

-Thom

[tschak909]

And yes, you're right, simple cases for other windowing systems (which I have written for) require dirtyrect management.

The difference is? almost all of the others have backing stores.

-Thom

[joska]

Sorry, Not feasible, since I am drawing color.

Are you referring to offscreen bitmaps here? They support the same colour depths as the actual screen driver. VDI without offscreen bitmaps only supports bitmap *conversion* to screen layout when the bitmap is monochrome, but if you implement your own drawing routines you can blit colour bitmaps to screen. However, in that case you must have custom drawing routines that handles all screen formats you want your program to support. No need for that with proper offscreen bitmaps.

However, while offscreen bitmaps makes things easier for the programmer they are not always the most efficient solution. Instead of writing to the screen you write to RAM, which could be faster (fast-RAM equipped machines, like TT or Falcon with CT2/Afterburner/CT60x) or slower (machines with hardware accelerated graphics, like a Hades, Milan, ATI-graphics card...) than drawing directly to screen. On top of that the finished bitmap must be blitted to screen. Unless you need to frequently redraw the same image it is probably more efficient to just draw directly to screen, atleast on lower spec hardware like the ST/STE.

[tschak909]

At least now I think I have a path forward that makes sense. (protocol actions cause screen queue insertions, redraws traverse rect list; set clipping and replay screen queue, duplicate coordinate and op sets are replaced)

And especially since I can check my list for drawing ops that directly overlap, and replace them, that will prevent the big problem that I ran into. I just need to make sure that drawing state is properly preserved...

Hopefully this will work well enough...

-Thom

[wongck]

I would do this as a TOS program, so that you get away from redraws of overlapping windows, etc...
In any case, most ST will not be running multitasking OS, so it's one program at a time, so you will not have that issue anyway.

[mfro]

Did you look into the code I linked to above? What are you missing?

[calimero]

What version of NVDI does support offscreen bitmaps?
Is NVDI free?
You could simple add NVDI.PRG to you Application .zip (distribution)

[ThorstenOtto]

What version of NVDI does support offscreen bitmaps?

I think it was version 3.01 or something.

Is NVDI free? You could simple add NVDI.PRG to you Application .zip (distribution)

No, its not free, that's why it might be a bad idea to add it to the archive. Of course there are lots of sites where it is available nevertheless.

[jfl]

Is NVDI free? You could simple add NVDI.PRG to you Application .zip (distribution)

No, its not free, that's why it might be a bad idea to add it to the archive.

Indeed. But there's also ENHANCER.PRG, which implements offscreen bitmaps and maybe other NVDI features and may be distributed. I think it's supposed to be used only under TOS. My limited tests under MiNT weren't convincing but that's a long time ago.

[ThorstenOtto]

But there's also ENHANCER.PRG,which implements offscreen bitmaps and maybe other NVDI features

Oh nice, didn't know that. That seems to be a good solution, that program is from the authors of NVDI. So all you have to do is to check for the EdDI cookie, which is installed by both NVDI and this program to indicate that offscreen bitmaps are available. According to the readme, ENHANCER only adds support for v_opnbm()/v_clsbm()/vq_scrninfo(), but that should be all you need.

[calimero]

That would be perfect solution for Plato and tschak909

btw
we should contact Andreas Kromke, maybe he is in touch with Behn brothers. Andreas start to put sources of his Atari related software on Gitlab... https://gitlab.com/AndreasK/Atari-Mac-MagiC-Sources maybe Behn brothers would do the same with Nvdi?

[tschak909]

Sorry, guys. I tried this, early on in development, if I add in an explicit requirement for NVDI, that pushes memory requirements to the point where a 1MB ST won't work.

-Thom

[tschak909]

I need to grind through trying to make a redraw algorithm that doesn't suck.

-Thom

[ThorstenOtto]

maybe Behn brothers would do the same with Nvdi?

I think he already asked them. The object files for some VDI parts are already there, just not the sources.

[ThorstenOtto]

Sorry, guys. I tried this, early on in development, if I add in an explicit requirement for NVDI, that pushes memory requirements to the point where a 1MB ST won't work.

-Thom

You should take a look at ENHANCER. It does not require NVDI, and is only 3k.

[lp]

Enhancer has a much smaller footprint than NVDI. I wrote a vdi demo using NVDI offscreen bitmaps however it does not work with Enhancer. All I get is a solid black blit. No idea why. I would suggest doing tests with Enhancer before getting to deep into any changes if you decide to go that route.

[tschak909]

I am currently working through trying to get window redraws working and optimized.

Code is winding up here in this branch:
https://github.com/tschak909/platoterms ... ueue_redux

-Thom

[joska]

I think it's supposed to be used only under TOS. My limited tests under MiNT weren't convincing but that's a long time ago.

I believe Enhancer implements offscreen bitmaps by manipulating VDI variables to "redirect" drawing offscreen. IIRC I had the same result as you with MiNT.

[tschak909]

Assuming I were to peel away the AES bits and just make this a TOS application, what's the correct method to initialize the display, and finally to hand it back to GEM?

-Thom

[arf]

[…] Using this (and the device specific VDI raster copy functions), you can draw into your own offscreen buffer (device specific format) and blit the result to the screen.

Beware that this covers all the basic Atari screen modes, but will not work on e.g. graphics cards of PC offspring that use linear framebuffer palette modes (like 256 colour VGA) and other "exotic" hardware (linear framebuffer palette modes should be trivial to implement, however).

But on Ataris with graphics cards, a modern VDI is very often given. And therefore offscreen bitmaps.

[arf]

Assuming I were to peel away the AES bits and just make this a TOS application, what's the correct method to initialize the display, and finally to hand it back to GEM?

On modern TOS versions/alternatives, you can’t really use TOS plus VDI only (or direct screen writes), without telling the AES "hey, block everything else". Which makes it no longer a TOS program, as there are AES calls. TOS programs were meant to be character driven/text only.

I understand that you don’t want to lose all the 1040STF/1 MB RAM users. But with a program blocking all other screen access, you lose a lot of today’s users with "modern" OSses like MagiC (1991) or MiNT (1991). Or Geneva.

Don’t want to discourage you, it’s just that "program displaying graphics" is either "make it with VDI within GEM windows" or "ignore the OS, ignore other applications, write dirty into screen mem like games". The path between the two extremes is dangerous, loads of work and typically quite incompatible.

[tschak909]

I'm already noticing that even with debugging the redraw issues, the performance eaten by attempting to maintain the screen queue is enough to make the modem miss incoming data. This is even in 25mhz on a TT030.

I will probably have to go back to my original mode of literally just painting over the top in full screen, only do full screen, and don't do any additional dialog boxes (for the keys/help menu).

poo.

(For the record, I am having none of these issues with any of the other ports, including the Amiga. GEM is an unbelievable pain in the arse.)

-Thom

[ThorstenOtto]

(For the record, I am having none of these issues with any of the other ports, including the Amiga. GEM is an unbelievable pain in the arse.)

I can't really believe that it is *that* much different. I don't know much about amiga, but the basic principle, that someone is telling you that you have to redraw your window, is almost the same everywhere.

[wongck]

I'm already noticing that even with debugging the redraw issues, the performance eaten by attempting to maintain the screen queue is enough to make the modem miss incoming data. This is even in 25mhz on a TT030.

The Atari ST base machine is 8Mhz with 512K and 720K floppy.
Make sure your program fits into that 720K floppy (plus other plumbing you need).
512K is not alot, so you probably use plain old screen painting TOS program that takes over the screen.

Then you have another version for higher end Atari like TT & Falcon etc that may use a Window over a multitasking OS.

[wongck]

I'm already noticing that even with debugging the redraw issues, the performance eaten by attempting to maintain the screen queue is enough to make the modem miss incoming data. T

Do you need to remember every bit of info that screen queue?
You just need to know those that are written currently on the 512x512 screen location.
It essentially like a game program, so some game developer may be helpful here.

Of course that throws the GEM/AES stuff out of the window and may gave issues running on Mint/Magix.