Must I use Display 1 for HW acc. stuff

Discuss OpenGL® programming with the GL Galore plugin here
Post Reply
User avatar
TheMartian
Posts: 109
Joined: Sun Feb 28, 2010 12:51 pm

Must I use Display 1 for HW acc. stuff

Post by TheMartian »

Hi

Was there a comment at some time to the effect, that you have to use Display 1 for HW accelerated stuff and GLGALORE?

I ask because if I replace the value for the constant that holds my display number from 1 to another number,when I set up my display, it acts as if I was using SW brushes etc. and gives the usual error when a HW brush is used without having defined BeginDoubleBuffer(True). Comments in the manual just says that BeginDoubleBuffer() works for the current display. So having created it with @DISPLAY and issued a SelectDisplay() before the BeginDoubleBuffer(True) statement, I assume it is indeed the current Display whether or not the default Display 1 is still around.

regards
Jesper
User avatar
TheMartian
Posts: 109
Joined: Sun Feb 28, 2010 12:51 pm

Re: Must I use Display 1 for HW acc. stuff

Post by TheMartian »

Hi

Ok. I think I found out where I went wrong. I had some code like this... and it works when I explicitly tell the brush to belong to Display 2 as in the example.

The problem is, that Display 1 is always implicitly in existence, unless it is deliberately removed. Also if I don't put the Display=<display number> parameter in the table with parameters for the @BRUSH statement, it assumes that I mean Display=1, and the brush works for Display 1. But now it works for Display #GAME_DISPLAY as it should.

NB! The 6.0 manual says on page 356 about the Display parameter, that it defaults to the currently active display. From what I see this is not correct. It always assumes Display 1 if no parameter is explicitly defined, as far as I can see.


I wrongly assumed that the brush would be assigned to the selected display if no explicit 'Display=' parameter was set, and tried to make sure I had det right display by using the SelectDisplay() statement.

Now the program creates a Display 2 with a BGPic (ScaledBGPic.png) and in Full Screen and makes sure it is the selected display. Actually it also displays Display 1 on top if Display 2. It also creates a Brush with the same content as the BGPic, which will be needed once we go to DoubleBuffer mode, which replaces the BGPic with whatever is in the buffer after the first Flip(). So having a brush with the same content that can be stamped in the buffer means it looks as if the BGPic is still present. The Wait statement is just there for testing purposes.

The program then creates a mapclass object, initializes it with a table of properties, plus modifying one of the properties (name$="JSP'2 fat map") and finally puts a lot of information from a matrix of data (map_data1). These functions are of course defined elsewhere and are not part of the example code.

Then the brush with the BGPic contents is stamped on display #GAME_DISPLAY, and finally I have created a utility function (displayAttributes) than will print the content of a multidimensional table nicely formatted to a software brush, which is then copied to a HW brush and stamped to a fixed position in the display buffer currently being painted. Then I do a Flip() and all is revealed and the Display 1 is no longer visible, because it is not part of the content in the stamped in the buffer. This listing of table contents is again just for debugging purposes.

regards
Jesper

@REQUIRE "glgalore"
Const #GAME_DISPLAY=2


@BGPIC #GAME_DISPLAY,"ScaledBGPic.png"
@DISPLAY #GAME_DISPLAY,{BGPic=#GAME_DISPLAY, Mode="FullScreen"}
SelectDisplay(#GAME_DISPLAY)
@BRUSH #NICE_PIC_HW,"ScaledBGPic.png",{Hardware=True, Display=#GAME_DISPLAY}

BeginDoubleBuffer(True)

Wait(100)

mymap=mapclass:new()
mymap:initAttributes({name$="JSP's fat map"})
mymap:initMap(map_data1)

DisplayBrush(#NICE_PIC_HW,0,0)
system:displayAttributes(mymap,0,True)

Flip()
User avatar
airsoftsoftwair
Posts: 5433
Joined: Fri Feb 12, 2010 2:33 pm
Location: Germany
Contact:

Re: Must I use Display 1 for HW acc. stuff

Post by airsoftsoftwair »

I've looked into this and there's quite a major bug in LoadBrush() when it comes to loading display-dependent hardware brushes. Basically, it's broken :) and can cause all sorts of weird issues including random crashes, so don't use it. Here are some alternatives:

1. Use the @BRUSH preprocessor command to load your display-dependent hardware brushes.
2. If you can't / don't want to use @BRUSH for some reason, use LoadBrush() to load the image into a temporary software brush first and then use CopyBrush() to turn that software brush into a display-dependent hardware brush, i.e. something like:

Code: Select all

tmp = LoadBrush(Nil, "test.png")
the_real_deal = CopyBrush(tmp, Nil, {Hardware = True, Display = ...})
FreeBrush(tmp)
This is of course some overhead but you can revert to LoadBrush() once I have fixed it for display-dependent hardware brushes :)

Thanks for the report! This is quite an issue and needs to be fixed.
User avatar
TheMartian
Posts: 109
Joined: Sun Feb 28, 2010 12:51 pm

Re: Must I use Display 1 for HW acc. stuff

Post by TheMartian »

Hi

Using @BRUSH with an explicitly assigned display will do just fine. Thanks :)

regards
Jesper
Post Reply