Lazarus

Programming => General => Topic started by: Alextp on August 10, 2020, 09:58:24 am

Title: Port "voxel" DOS demo to Lazarus
Post by: Alextp on August 10, 2020, 09:58:24 am
https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/demo/modex/voxel.pp?view=markup&revision=3&root=fpcbuild

I need to know what to do with
procedure draw(xp,yp,dir:integer);
-it does this to clear data:   fillchar(scr^,64000,0);
-it puts data to some DOS memory:   Move(Scr^,mem[$A000:0],64000);

How to show this data (array with 64K size) on Lazarus canvas?

Title: Re: Port "voxel" DOS demo to Lazarus
Post by: marcov on August 10, 2020, 09:59:34 am
Draw every pixel. The whole idea of ModeX was that the screen was linear in 64kb memory as typically an 8-bit color paletted image.

 Maybe it is easiest to use opengl, and treat it as texture, with and 1D texture for lookup
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Alextp on August 10, 2020, 10:06:22 am
Found it https://en.wikipedia.org/wiki/Mode_X
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Alextp on August 10, 2020, 10:44:11 am
I have now such picture-- is it like DOS one?
What is DOS look?

(Arrow keys work OK, but colors...)
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: marcov on August 10, 2020, 10:46:53 am
It's long ago, but I don't remember those colors. Maybe bgr vs rgb ?
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 10, 2020, 10:51:13 am
That does not seem really to be modeX in the code. Rather a bitmap where each pixel is a bye index to a palette.

EDIT: Oh that is non planar modeX, ok.

You could create an TLazIntfImage with this data, then create the TBitmap and draw it.

Or update an RGBA bitmap with the color from the palette (using BGRABitmap, Graphics32, OpenGL etc.)
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 10, 2020, 10:52:15 am
I have now such picture-- is it like DOS one?
What is DOS look?

(Arrow keys work OK, but colors...)
The palette color values were sent via the Port. So it means that they are from 0 to 63 instead of 0 to 255.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Alextp on August 10, 2020, 10:58:51 am
Seems done!
https://github.com/Alexey-T/Voxel_demo_Lazarus
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 10, 2020, 01:36:10 pm
Not sure, how to do it in portable style, but on Windows it's better to draw on memory bitmap and then use SetDIBitsToDevice (https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-setdibitstodevice) or StretchDIBits (https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-stretchdibits) to draw it on canvas with hardware acceleration. Only thing to note - by default DI bitmap is upside-down. I guess, CreateDIBSection (https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createdibsection) is also suitable for this purpose, but I haven't used it in my projects.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 10, 2020, 04:07:46 pm
You can use TBGRABitmap to implicitly use a DIB bitmap.

Though in this case, using an TLazIntfImage with a palette might be faster.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Alextp on August 10, 2020, 04:28:20 pm
I am done with porting, all on github. IMO change for LazIntfImage isn't needed.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 10, 2020, 08:09:06 pm
It's better to do it, as it's 100 times faster.

P.S. In CODE2 I've tried to avoid unnecessary extra Canvas.Draw.

P.P.S. And yeah. Original example doesn't actually use ModeX. It's just plain simple Mode13 with "software" double buffering, that is very reliable, as it doesn't require VSync (forced for VGA - page flip just can't occur in a middle of a frame), but at the same time very slow.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Alextp on August 10, 2020, 10:35:45 pm
Applied to repo: with CODE1 define, to use it here on Linux.

You are good.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 10, 2020, 11:45:25 pm
Nice @Mr.Madguy

One memory leak though: the Header is allocated each time.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 11, 2020, 07:39:06 am
Nice @Mr.Madguy

One memory leak though: the Header is allocated each time.
It's allocated in OnCreate, freed in OnDestroy and it's "local" form variable. It shouldn't be memory leak.

I have never used BGRABitmap or TLazIntfImage, so I couldn't implement it in portable fashion. But, I guess, this two use something like SetDIBitsToDevice internally anyway. I'll try to do it today.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 11, 2020, 09:18:37 am
Couldn't implement it via TLazIntfImage, as it says, that it currently doesn't support palettes. I've implemented it via TBGRABitmap. See CODE4. Still 5 times slower than my code. Also I've cleaned up code and made it portable (I guess).
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 11, 2020, 10:07:02 am
I've implemented TLazIntfImage code via ARGB data type the same way, TBGRABitmap code is implemented. Faster, but still 3 times slower, than raw SetDIBitsToDevice.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 11, 2020, 10:39:04 am
Oh you're right, I thought that header was created each time.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Alextp on August 11, 2020, 10:50:00 am
Good. Posted your version to github!
(for next update, pls format the unit1.pas - indents should be 2 spaces, no tab's)
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 11, 2020, 12:09:58 pm
I think that using TImage does not give accurate result. Indeed, when doing so, the screen update is postponed to the OnPaint event of TImage, thus not counted in the time.

I replaced Code2 by drawing pixels directly on the Panel.

There was a problem with the line order and byte order of the BGRABitmap (it can change depending on the platform). I've also used precomputed palettes to hopefully optimize.

I don't get any difference between TLazIntfImage and TBGRABitmap, I get 10 ms in both cases. Note that TLazIntfImage could be optimized by using a palette.

MacOS 64bits
---------------
Code1 (bmp pixels): 88ms
Code2 (panel pixels): 77.5ms
Code3 (DIB): N/A
Code4 (BGRA): 10.5ms
Code5 (Intf): 10ms

Can you give me your times with this version?
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 11, 2020, 12:25:52 pm
Note that TLazIntfImage could be optimized by using a palette.
How can I do it? TLazIntfImage doesn't provide direct access to palette and direct TRawImage usage doesn't work for me (see CODE6). Once I set RawImageDesc.PaletteColorCount = 256, screen just goes blank.

P.S. CODE5 is a little bit optimized. CODE6 is even faster, than SetDIBitsToDevice.

P.P.S. Ohhhh. And another one. I have Lazarus 1.8.2 and LoadFromRawImage has memory leak for ADataOwner = True, because it calls CreateData in GetRawImagePtr, but doesn't clean this old data up. I've fixed this bug on my local copy of Graphics.pas.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Alextp on August 11, 2020, 12:29:56 pm
Good, @circular. Updated- https://github.com/Alexey-T/Voxel_demo_Lazarus
Mr.Madguy, I welcome update over github version.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 11, 2020, 12:39:13 pm
Can you give me your times with this version?
CODE1: 32ms
CODE2: 56ms
CODE3: 0.33ms
CODE4: 0.46ms
CODE5: 0.70ms, but bugged - shows wrong picture and throws exception at termination
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 11, 2020, 12:40:56 pm
Mr.Madguy, as I mentioned before, the times you had do not include the actual drawing on the screen, because the TImage will update the screen after the UpdateImage procedure.

Are those new results with my version?
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 11, 2020, 12:48:40 pm
Does not seem possible to me that BGRA would be so slow. And neither that accessing bitmap pixels would be so fast. For the DIB too, I find the timing very low.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 11, 2020, 12:57:40 pm
Does not seem possible to me that BGRA would be so slow. And neither that accessing bitmap pixels would be so fast. For the DIB too, I find the timing very low.
Oh, of course 0.48ms
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 11, 2020, 01:02:03 pm
It makes sense to me that SetDIBitsToDevice would be the fastest on Windows, even though that's not portable.

Ok so BGRA is 42% slower than using DIB with palette. That makes sense, because it contains RGBA information for each pixel, that's 4 times more information to copy.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 11, 2020, 01:09:22 pm
Ok, my final version with precomputed palettes implemented. I know, that TImage code isn't accurate, but I like it more. CODE6 doesn't fully work. I guess, because something about "hardware" palettes isn't fully implemented in FPC.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 11, 2020, 01:14:16 pm
Where is this final version?

By the way, what was the display error with Code5 with my version on your computer? Can you provide a screenshot?

About TImage, that does not provide the actual drawing times, at least on MacOS and Linux.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 11, 2020, 01:16:49 pm
Good. Posted your version to github!
(for next update, pls format the unit1.pas - indents should be 2 spaces, no tab's)
Thanks. I will suggest a fork if I can make the TLazIntfImage with palette work.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Alextp on August 11, 2020, 01:24:01 pm
Mr.Madguy had posted his code in attachment in zip.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 11, 2020, 01:31:08 pm
Oh indeed. I suppose Madguy posted it afterwards.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 11, 2020, 01:32:09 pm
Where is this final version?

By the way, what was the display error with Code5 with my version on your computer? Can you provide a screenshot?

About TImage, that does not provide the actual drawing times, at least on MacOS and Linux.
This and RunError(204) at termination. Mine version works properly.

P.S. SetDIBitsToDevice is fastest because you draw directly on output surface. It's the best way to simulate VGA Mode13 on Windows. I use it in my universal (same EXE!) DOS/Win BMP View project. But at the end it can be a little slower than hardware BLT on modern hardware, because it's in system memory - not in video memory, as TBitmap is.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 11, 2020, 01:52:50 pm
This and RunError(204) at termination. Mine version works properly.
Hmmm, though your version did not work on my computer.

Thanks for the screenshot. It seems there is a problem of alignment, maybe because without an alpha channel, it makes 3 bytes long pixels.

Here is a pull request to hopefully fix that using RGBA format. It is a tiny bit slower by 0.5 ms on my computer.
https://github.com/Alexey-T/Voxel_demo_Lazarus/pull/1
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 11, 2020, 01:58:35 pm
This and RunError(204) at termination. Mine version works properly.
Hmmm, though your version did not work on my computer.

Thanks for the screenshot. It seems there is a problem of alignment, maybe because without an alpha channel, it makes 3 bytes long pixels.

Here is a pull request to hopefully fix that using RGBA format. It is a tiny bit slower by 0.5 ms on my computer.
https://github.com/Alexey-T/Voxel_demo_Lazarus/pull/1
And what was wrong with my version? Blank screen? May be I should set Alpha to $ff?

P.S. Try this version with Alpha channel handled properly.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 11, 2020, 02:07:10 pm
The problem was related with the byte order of the channels. You need to look in the image description to know the offset (bit shift) of each channel.

As I have a Retina display, I tried again measuring times displaying at actual pixel size (so 2x smaller). I get the following times:

MacOS 64-bit without Retina scaling
----------------------------------------
Code1: 79ms
Code2: N/A (pixels cannot be accessed)
Code3: N/A (Windows only)
Code4: 2ms
Code5: 2ms
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: BeanzMaster on August 11, 2020, 06:20:31 pm
Hi to all, interesting, sometime ago i converted this voxel

We can improve performances by :
1) Using LUT for Sin and Cos
2) Avoid one mul and 4 sub
3) Drawing directly in the "bitmap buffer" instead of in Src (except for CODE 3)

What i do
1) I've added a rendering with the help of my own lib BZScene (https://github.com/jdelauney/BZScene) (CODE6) see GIF : https://imgbox.com/3WIFJgE8#
2) Improve BGRABitmap (CODE4)
3) Fix compatibility with TLazIntfImage (CODE5)
4) Introduce Sin and Cos LUT
5) Improve a little bit calculus (avoid one mul and 4 sub)
6) Added an auto travel throught the world (press key "A" to start)

Now the benchmark the results are the average frame speed of the travel (press key "A")

CPU            : AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G

Compiled in Release mode and full optimization

Under Windows 64 bits with FPC 3.2 and Lazarus 2.0.10 :

CODE 1 : 64,6442 ms
CODE 2 : 63,2677 ms
CODE 3 :  0,3597 ms
CODE 4 : 1,3309 ms
CODE 5 : 1,3684 ms
CODE 6 : 0,9012 ms

Under Linux (Manjaro) - GTK 2 - with FPC 3.0.4 and Lazarus 2.0.8 (Bench is not accurate)

CODE 1 : 17,9941 ms
CODE 2 : 18,1594 ms
CODE 3 : N/A
CODE 4 : 3,0521 ms
CODE 5 : 3,9579 ms
CODE 6 : 2,6569 ms

See the attached ZIP for code

Cheers


Title: Re: Port "voxel" DOS demo to Lazarus
Post by: BeanzMaster on August 11, 2020, 06:31:50 pm
if you are interested by voxel landscape if i'm remember well Circular you have made one with BGRABitmap some time ago ( but forgot where to find it)

You can also take a look at one of my BZScene's demo  : https://github.com/jdelauney/BZScene-Samples/tree/master/Graphics/CommancheVoxel based on https://s-macke.github.io/VoxelSpace/VoxelSpace.html
https://www.youtube.com/watch?v=1ytUbSiUvjk  The landscape is rendering with a resolution of 1024x768 (sorry for the quality of this video)

Cheers
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 11, 2020, 07:36:45 pm
Hi BeanzMaster,

Maybe you can make a pull requests with your changes on the repository:
https://github.com/Alexey-T/Voxel_demo_Lazarus

I did indeed tamper with voxel and added vertical walls:
https://github.com/bgrabitmap/demo/tree/master/voxel
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Alextp on August 11, 2020, 08:02:06 pm
Yes, I welcome pull-req so I don't need to merge by hands.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: BeanzMaster on August 11, 2020, 08:59:37 pm
Yes, I welcome pull-req so I don't need to merge by hands.

No problem i'll do and pull a request
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: BeanzMaster on August 12, 2020, 01:10:52 pm
Hi to all

Pull request send ;)

This is the new benchmark :

Code: Pascal  [Select][+][-]
  1.  ______________________________________________________________________________
  2.  |  CPU     : AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G                 |
  3.  |  OS      : Windows 10 64bit                                                |
  4.  |  FPC     : 3.2.0                                                           |
  5.  |  LAZARUS : 2.0.10                                                          |
  6.  |____________________________________________________________________________|
  7.  |  MEHTOD |  CODE 1  |  CODE 2  |  CODE 3  |  CODE 4  |  CODE 5  |  CODE 6   |
  8.  |=========|==========|==========|==========|==========|==========|===========|
  9.  |  Debug  | 39,9572  | 686,1903 |  0,5434  |  1,2037  |  1,5852  |  0,8171   |
  10.  |---------|----------|----------|----------|----------|----------|-----------|
  11.  | Release | 38,7973  | 671,5684 |  0,4201  |  1,0717  |  1,3234  |  0,7014   |
  12.  |----------------------------------------------------------------------------|
  13.  
  14.  ______________________________________________________________________________
  15.  |  CPU     : AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G                 |
  16.  |  OS      : Linux Manjaro 64bit                                             |
  17.  |  FPC     : 3.2.0                                                           |
  18.  |  LAZARUS : 2.0.10                                                          |
  19.  |____________________________________________________________________________|
  20.  |  MEHTOD |  CODE 1  |  CODE 2  |  CODE 3  |  CODE 4  |  CODE 5  |  CODE 6   |
  21.  |=========|==========|==========|==========|==========|==========|===========|
  22.  |  Debug  | 11,2772  |  35,1391 |   N/A    |  2,3768  |  3,1898  |  2,1478   |
  23.  |---------|----------|----------|----------|----------|----------|-----------|
  24.  | Release | 11,2917  |  37,6608 |   N/A    |  2,1562  |  2,7684  |  2,0740   |
  25.  |----------------------------------------------------------------------------|

We can see Canvas method (CODE2) under Windows is a pit of doom
With IntfImage (CODE5) background is not cleared. The Bitmap is drawn on canvas with transparency, don't say why  :o

Under Linux :
  with CODE1 and CODE2 performances are little bit better in Debug mode than Release mode  :o
  BGRABitmap CODE4 and BZScene CODE6 are the best and are very close
 
Under Windows :
  the native method is the best and after is BZScene, which are below one ms

Under Windows and Linux : IntfImage CODE5 is a little slower than CODE4 and CODE6.

Cheers


Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Alextp on August 12, 2020, 01:20:16 pm
Good, tkx. If you can 'isolate' that pit of doom, in some small win32 demo- it may help to fix it...
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: BeanzMaster on August 12, 2020, 01:34:30 pm
Good, tkx. If you can 'isolate' that pit of doom, in some small win32 demo- it may help to fix it...

It seems to be something with LCL Canvas methods and Windows.
Perhaps by using a TPaintBox it will be better
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Alextp on August 12, 2020, 01:41:35 pm
We can 'isolate' the slowdown on some demo? I didn't read code detailed.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: BeanzMaster on August 12, 2020, 01:57:46 pm
We can 'isolate' the slowdown on some demo? I didn't read code detailed.

I don't think it's seems to be internal to the widget and on how canvas is refreshed. or it's simply specific to windows but i don't think because CODE3 is very fast  %)
The problem seems come from "control.canvas.pixel[x,y]" access,  is not locked like with CODE1 and the bitmap BeginUpdate/EndUpdate.
We can also see the display is not "v"-sync. because we draw directly on the canvas, we don't have a buffer like CODE1
If we compare benchmark CODE1.  Windows is around 4/5x slower than Linux.

I compiled in win32 the result is the same
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 12, 2020, 03:27:55 pm
Looks like there is some difference between calling UpdateImage inside and outside of OnPaint. Outside is 4x slower for me. It can be fixed via adding "and not(defined(CODE2))" to OnTimer event.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: BeanzMaster on August 12, 2020, 04:19:56 pm
Looks like there is some difference between calling UpdateImage inside and outside of OnPaint. Outside is 4x slower for me. It can be fixed via adding "and not(defined(CODE2))" to OnTimer event.

Hi, You're right {$IFDEF} can be remove in the onTimer event  :-[

without CODE2 run around 187 ms/frame  :)
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: BeanzMaster on August 12, 2020, 05:15:44 pm
Update ready

New benchmark

Now under windows
 - CODE2 is 4x time faster
 - BGRABitmap CODE4 in release mode is under 1 ms

Globally performances are little bit better

Note by lauching application outside IDE, performances are little bit better  :D

Code: Pascal  [Select][+][-]
  1.                            (Run inside IDE)
  2.  ______________________________________________________________________________
  3.  |  CPU     : AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G                 |
  4.  |  OS      : Windows 10 64bit                                                |
  5.  |  FPC     : 3.2.0                                                           |
  6.  |  LAZARUS : 2.0.10                                                          |
  7.  |____________________________________________________________________________|
  8.  |  METHOD |  CODE 1  |  CODE 2  |  CODE 3  |  CODE 4  |  CODE 5  |  CODE 6   |
  9.  |=========|==========|==========|==========|==========|==========|===========|
  10.  |  Debug  | 32,9288  | 179,0486 |  0,3927  |  1,1459  |  1,6595  |  0,7231   |
  11.  |---------|----------|----------|----------|----------|----------|-----------|
  12.  | Release | 33,7899  | 175,9073 |  0,3314  |  0,9093  |  1,3172  |  0,6364   |
  13.  |----------------------------------------------------------------------------|
  14.  
  15.  ______________________________________________________________________________
  16.  |  CPU     : AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G                 |
  17.  |  OS      : Linux Manjaro 64bit                                             |
  18.  |  FPC     : 3.2.0                                                           |
  19.  |  LAZARUS : 2.0.10                                                          |
  20.  |____________________________________________________________________________|
  21.  |  METHOD |  CODE 1  |  CODE 2  |  CODE 3  |  CODE 4  |  CODE 5  |  CODE 6   |
  22.  |=========|==========|==========|==========|==========|==========|===========|
  23.  |  Debug  |  9,6536  |  28,8853 |   N/A    |  2,5927  |  3,5188  |  2,2695   |
  24.  |---------|----------|----------|----------|----------|----------|-----------|
  25.  | Release | 10,0101  |  29,9593 |   N/A    |  2,2685  |  3,0899  |  2,0943   |
  26.  |----------------------------------------------------------------------------|
  27.  
 
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 12, 2020, 07:05:09 pm
Note that drawing outside of OnPaint event is not possible on MacOS.

EDIT: I tried running BZScene on MacOS but it doesn't compile. The unit BZSystem uses linux and users units but they are not found.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 12, 2020, 08:09:58 pm
I've added support for Retina display. I have the following times:
Code: [Select]
                                   circular
                               (Run inside IDE)
 ______________________________________________________________________________
 |  CPU     : 3 GHz Intel Core i5 6 cores                                     |
 |  OS      : MacOS Catalina (64bit)                                          |
 |  FPC     : 3.2.0                                                           |
 |  LAZARUS : 2.0.10                                                          |
 |____________________________________________________________________________|
 |  METHOD |  CODE 1  |  CODE 2  |  CODE 3  |  CODE 4  |  CODE 5  |  CODE 6   |
 |=========|==========|==========|==========|==========|==========|===========|
 |  Debug  | 63 - 112 | 140 - 143|   N/A    |  1 - 2   |   2 - 3  |     ?     |
 |---------|----------|----------|----------|----------|----------|-----------|
 | Release | 21 - 75  | 79 - 81  |   N/A    |  1 - 2   |   1 - 2  |     ?     |
 |----------------------------------------------------------------------------|
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: BeanzMaster on August 12, 2020, 09:10:56 pm
Note that drawing outside of OnPaint event is not possible on MacOS.

EDIT: I tried running BZScene on MacOS but it doesn't compile. The unit BZSystem uses linux and users units but they are not found.

Hi I'll add support for MacOs  when i'll have more time. I'm sure it will be not hard. Surely need to add some $IFDEF

Thanks for report  8)
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: BeanzMaster on August 13, 2020, 03:52:48 pm
Hi to all today i've updated my mac and install the latest Lazarus.
I've worked on BZScene to get compatible with MacOS.

This is the benchmark i did on my iMac

 
Code: Pascal  [Select][+][-]
  1. ______________________________________________________________________________
  2.  |  CPU     : Intel(R) Core(TM) i5 CPU 750 2.67Ghz                            |
  3.  |  OS      : iMac - MacOS High Sierra 64 bits - Widget set : COCOA           |
  4.  |  FPC     : 3.2.0                                                           |
  5.  |  LAZARUS : 2.0.10                                                          |
  6.  |____________________________________________________________________________|
  7.  |  METHOD |  CODE 1  |  CODE 2  |  CODE 3  |  CODE 4  |  CODE 5  |  CODE 6   |
  8.  |=========|==========|==========|==========|==========|==========|===========|
  9.  |  Debug  | 139,8880 | 984,8184 |   N/A    | 2,5060   |  3,1831  |  2,7487   |
  10.  |---------|----------|----------|----------|----------|----------|-----------|
  11.  | Release |  84,1881 | 833,1344 |   N/A    | 2.1283   |  2,7723  |  2,5091   |
  12.  |----------------------------------------------------------------------------|


Like we see on my machine BGRABitmap is the best, closely follow by BZScene and by CODE5 in release and debug mode.
Unfortunally on my Mac CODE2 is a very big pit of doom  :o and CODE1 is cleary less performant rather than Windows and Linux
 
I'll update BZScene repo soon as possible

Cheers
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 13, 2020, 06:59:36 pm
Seems like CODE7 is even faster than CODE3, because it doesn't have any bitmap copy operations at all. But in case of Panel1.Canvas there shoudn't be difference, because it requires one bitmap copy anyway.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Alextp on August 13, 2020, 08:12:46 pm
Maybe someone will make pull-req for CODE7?
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: BeanzMaster on August 13, 2020, 08:54:35 pm
Maybe someone will make pull-req for CODE7?

Hi
I'll can tomorrow  :D
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 14, 2020, 10:37:13 am
I would add initial DOS support to this project including actual ModeX (actually ModeY, as we want 320x200), if somebody would explain, how to compile it on DOS. I tried to do it, installed DOS cross compile package, put got "can't execute ppc8086" error and direct execution of ppcross8086 was giving me "Can't find system unit for your platform" or something like that.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: BeanzMaster on August 14, 2020, 01:11:13 pm
Seems like CODE7 is even faster than CODE3, because it doesn't have any bitmap copy operations at all. But in case of Panel1.Canvas there shoudn't be difference, because it requires one bitmap copy anyway.

Hi

I take a look to your code

CODE7 is a little bit less efficient rather than CODE3
In CODE3 the "Bitmap" is direclty displayed on Canvas and is more efficient than CODE7.
In CODE7 you don't see the "copy" because the display is managing internally by the TImage

Your CODE6 is bugged, the landscape is in a red shade

Note in the code from repo we have deleted the TImage Bitmap is directly displayed on Panel.Canvas

Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 14, 2020, 05:48:37 pm
Hi

I take a look to your code

CODE7 is a little bit less efficient rather than CODE3
In CODE3 the "Bitmap" is direclty displayed on Canvas and is more efficient than CODE7.
In CODE7 you don't see the "copy" because the display is managing internally by the TImage

Your CODE6 is bugged, the landscape is in a red shade

Note in the code from repo we have deleted the TImage Bitmap is directly displayed on Panel.Canvas
I've said about both cases. Yeah, CODE7 isn't better in case of TPanel, but it is in case of TImage. And CODE6 doesn't work properly, because if I enable palette, screen just goes blank. Palette is disabled and without it red color is used.

About DOS example. I've managed to compile it and implement ModeY (see CODE2). It's true "hardware" implementation - not lazy "software" one. That's why it's so complicated. Not sure, if it's faster or not. Couldn't combine it with first project, because go32v2 cross compiler requires packages to be deleted, but throws internal error anyway. I guess, that's because it requires program to be simple pas file - not project.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 14, 2020, 06:10:38 pm
Yeah, CODE7 isn't better in case of TPanel, but it is in case of TImage.
I guess you're not getting it. TImage rendering is drawn in another event, so the actual drawing on the screen in not taken into account. Hence you get a lower time, but it does not count everything.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 14, 2020, 06:38:30 pm
I guess you're not getting it. TImage rendering is drawn in another event, so the actual drawing on the screen in not taken into account. Hence you get a lower time, but it does not count everything.
I understand it. I've already said, that TImage does one bitmap copy internally, that my program doesn't count. And TPanel would require this step to be done manually anyway, so using DIB section is pointless, except may be it has more optimal internal implementation, than pure DIB. I just tried to say, that overall one bitmap copy is faster than two in case of TImage.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 14, 2020, 07:12:55 pm
I've managed to merge Windows and DOS demos into one project! Internal errors have been caused by debug info. But I have only one problem to solve. How can I add LCL and BRGABitmap packages only to specific build modes? Is there some simple way to do it or I will have to use some crutch solution, like manually adding search paths?
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: circular on August 14, 2020, 07:41:09 pm
That's a good question. I suppose dependencies do not depend on the build mode either.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 14, 2020, 08:02:35 pm
That's a good question. I suppose dependencies do not depend on the build mode either.
I don't know, how to do it. Hardcoding search paths isn't good idea. And there is no easy way to do it, as for example add "-PLCL -PBGRABitmap" options to build mode. So here it is. With little optimization for ModeY - DosMemPut should be faster. There is even faster way - to access memory directly. But it requires asm code, I guess, as it's the only way to deal with selector in 32bit mode.

In order to compile DOS version you need to install cross compiler (http://ftp://ftp.freepascal.org/pub/fpc/contrib/cross/mingw/binutils-2.15-win32-i386-go32.zip), extract units from here (http://ftp://ftp.freepascal.org/pub/fpc/dist/3.0.4/i386-go32v2/dos304full.zip) and choose Dos build mode. Problem is - you need to manually remove packages, cuz they won't compile in this mode. Program requires DOSBox or other DOS emulator to run. Or FreeDOS installed on real machine. Not sure, but CWSDPMI may be required.

CODE1 - initial Mode13 with lazy software double buffering
CODE2 - ModeY (320x200) with direct rendering and hardware double buffering (feels slower, than it should be, but fixing it would overcomplicate things)
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: josh on August 14, 2020, 08:03:43 pm
You could try
Code: [Select]
{$ifdef lcl}{$endif}
use it in your uses definition to bring in things like forms and bgrabitmap ie.

Code: [Select]
Uses Classes, SysUtils{$ifdef lcl}, Forms, BgraBitmap, Controls, Graphics, Dialogs{$endif};

I have not tested but it may help
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 14, 2020, 08:08:34 pm
You could try
Code: [Select]
{$ifdef lcl}{$endif}
use it in your uses definition to bring in things like forms and bgrabitmap ie.

Code: [Select]
Uses Classes, SysUtils{$ifdef lcl}, Forms, BgraBitmap, Controls, Graphics, Dialogs{$endif};

I have not tested but it may help
I use {$IFDEF go32v2} and it completely removes whole Windows code. Problem is - it's IDE packages, that refuse to compile.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: josh on August 14, 2020, 08:14:51 pm
You could also add custom defines to each build mode.
Project->Options->Custom Options
You can then create custom defines for each build mode, and turn on/off which custom define per each build.

ie
{$ifdef VOX_USE_BGRABITMAP} add your stuff {$endif}


Added Just read your above post, was not aware that it was a package issue. Apologies
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: Mr.Madguy on August 14, 2020, 09:22:23 pm
Ahhhhh. I've found out, that Crt was missing (this should have been wrong!), because DOSBox, I used to install Go32v2 version of FPC, didn't have LFN support. Forced installation of Crt and now manual ReadKey implementation is no longer needed again.
Title: Re: Port "voxel" DOS demo to Lazarus
Post by: julkas on August 16, 2020, 01:55:26 pm
DosBox & TP7
TinyPortal © 2005-2018