How often does Freebasic update the screen?

[lassar]

How often does Freebasic update the screen from the frame buffer?

Is there a way not to use the framebuffer, but draw directly to video memory.

A couple of ideas come to mind.

Code: Select all

ScreenControl SET_DRIVER_NAME

OR 

ScreenRes width, height , depth , num_pages , GFX_OPENGL

What is the way to directly draw to video memory?

If it's not possible then how about adding this feature to the dos freebasic.

It should be very easy to add.

[MichaelW]

Is there a way not to use the framebuffer, but draw directly to video memory.

Drawing directly to the video memory presents problems with flicker and tearing. The point of using a framebuffer is so the drawing operations can update the invisible framebuffer, and the update of the visible video memory can be done in a fast memory-copy operation. When you draw directly to the video memory the update is done at the speed of the drawing operations, which are typically much slower than a memory-copy operation. Problems with flicker and tearing are usually the result of the video memory update overtaking the screen refresh, or the screen refresh overtaking the video memory update. This causes either the lower (update overtaking refresh) or the upper (refresh overtaking update) part of the update area to appear first, followed by the other part during the next refresh cycle. The normal solution for this is to sync the update with the screen refresh by starting the update at the start of vertical retrace. But this will not solve the problem if the update is slower than the refresh and it takes longer than one vertical frame period, conditions that are more likely to occur when drawing directly to the video memory.

[lassar]

The reason I asked is, I am trying to get the most speed out of a program.

This program will run anywhere from 1000 cycles to 3000 cycles. (using a dos emulator for mobile devices)

I need to get the most speed out of it as possible.

It uses assembly for 99% of the graphics.

If I can write directly to the screen, I can at least double the speed of program.

That's nothing to be sneezed at.

And the writing directly to the video has to look better, then the frame skips, that dosbox can do.

[badidea]

You wan to display at 1000 - 3000 times per second? Do I understand that right? Then with what monitor and which superhuman to watch?

Can you you not just have your main loop running faster then your graphical/text updating loop?

I haven't used DOS for 20 years so I might be talking nonsense.

[lassar]

DosBox dos emulator has it so you can slow down dos programs.

From what I read about dosbox dos emulator, 1000 to 3000 cycles is about equal to a 386 running from about 3 MHZ to 25 Mhz.

If you tried regular freebasic graphics commands at this speed, watching the screen would be like watching the grass grow.

Slowly.....drawing.....to.....the.....screen.

I read that dos emulators on mobile devices run some where around 4000 cycles depending on the speed of the mobile device.

I want my program to run at a decent speed on the slowest of mobile devices.

[marcov]

You have to phrase your questions better. People have already told you several times that there usually is no relation between general dos performance and performance of an emulator on a mobile device that must emulate hardware.

[MichaelW]

In general, the slower the processor the longer the drawing operations take, so unless the refresh rate is reduced proportionally, the problem with flicker and tearing will increase. Before you put more time in this I suggest that you examine graphics of the sort that you expect to use, drawn to the video memory with no sync.