Hi,
i just snapshotted my stuff with various fixes, to make it load cleanly on pharo and squeak images.
I'd like you to ask to test and load it and tell me if it works for you.
Currently it works only on win32 platform. It could work on Linux, but i didn't had time to port it yet.
There is no automatic installation procedure right now, so here what you should try:
- first, you need to have VM with NativeBoost plugin + NativeBoost loaded into an image (see http://code.google.com/p/nativeboost/wiki/Installation for instructions)
- then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL in following order:
- NBOpenGL-Core - NBOpenGL-Win - NBOpenGL-TrueType - NBOpenGL-Display - NBOpenGL-Morphic
i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were released recently, and it seems works ok. on squeak/trunk it should also work without problems.
Now, if everything went right, then we're ready to run a demo:
GLViewportMorph new "useOwnForm: true;" openInWorld
This thing should render a TrueType glyphs and animating a smooth zoom of it. Nothing fancy, i just wanna know, if it works for you (and how well). :)
As you may know, GPU/OpenGL implementations vary depending on vendor and how old your hardware is, and i don't have all of it at my disposal.
Ok.. if you got it running, and it renders the glyphs.. there's one thing left: - save your image and quit (without closing this morph) - start image
it should continue working as if nothing happens.
On Mon, 24 May 2010 09:03:24 -0500, Igor Stasenko siguctua@gmail.com wrote:
Hi,
i just snapshotted my stuff with various fixes, to make it load cleanly on pharo and squeak images.
I'd like you to ask to test and load it and tell me if it works for you.
Beautiful! Works exactly as you describe; I'm on an older Windows XP system, 2.2ghz Athlon, 512M ram, NVidia 6200 graphics card w/ 256MB. The animation loop's running fast and smooth, and doesn't seem to be giving much cpu load.
I'm using a fresh trunk image, running the VM listed in your install instructions.
The second line of text starts with some cyrillic-looking characters; but in the Squeak system browser for GLViewportMorph>>drawOn: the string shows with question marks; so I guess that thing you're doing with the truetype code block might be working.
it should continue working as if nothing happens.
Yep. Very cool!
Kevin Kelley
On 24 May 2010 20:20, Kevin Kelley kevin@kelleysoft.com wrote:
On Mon, 24 May 2010 09:03:24 -0500, Igor Stasenko siguctua@gmail.com wrote:
Hi,
i just snapshotted my stuff with various fixes, to make it load cleanly on pharo and squeak images.
I'd like you to ask to test and load it and tell me if it works for you.
Beautiful! Works exactly as you describe; I'm on an older Windows XP system, 2.2ghz Athlon, 512M ram, NVidia 6200 graphics card w/ 256MB. The animation loop's running fast and smooth, and doesn't seem to be giving much cpu load.
Well, actually it does :) I implemented it specifically to be embedded into a squeak's Display, so i could run it and see what happens, without any distortion/visual artifacts and keep working while it runs.
First, it renders everything into offscreen surface, and then it reads results from video memory into a display form, and then DisplayScreen + VM takes care about blitting that form back to video memory (or anywhere else it wants).
In case if we will replace all drawing by using GL, then we won't need to blit bits back to system memory, and then all processing will be completely performed by GPU. It will be much faster.
You can see how much slowdown is introduced by blitting, if you resize the morph to cover full screen.
I'm using a fresh trunk image, running the VM listed in your install instructions.
The second line of text starts with some cyrillic-looking characters; but in the Squeak system browser for GLViewportMorph>>drawOn: the string shows with question marks; so I guess that thing you're doing with the truetype code block might be working.
Yes, it works as i described (in other thread). I subclassed TTFontReader to support reading character maps with pId=3, allowing you to use all glyphs of windoze fonts.
it should continue working as if nothing happens.
Yep. Very cool!
Kevin Kelley
Btw, i noticed that running it full-screen in pharo is still quite fast and smooth, which makes me wonder, what extra a squeak image does to perform blitting on screen. Something slows things down there.
In both images, i used:
Display depth 32 Display isLittleEndian true
On Mon, 24 May 2010, Igor Stasenko wrote:
Btw, i noticed that running it full-screen in pharo is still quite fast and smooth, which makes me wonder, what extra a squeak image does to perform blitting on screen. Something slows things down there.
Did you try the profiler (Extras menu)? I found it pretty useful when I was hacking RFB recently.
Levente
In both images, i used:
Display depth 32 Display isLittleEndian true
-- Best regards, Igor Stasenko AKA sig.
On 24 May 2010 23:06, Levente Uzonyi leves@elte.hu wrote:
On Mon, 24 May 2010, Igor Stasenko wrote:
Btw, i noticed that running it full-screen in pharo is still quite fast and smooth, which makes me wonder, what extra a squeak image does to perform blitting on screen. Something slows things down there.
Did you try the profiler (Extras menu)? I found it pretty useful when I was hacking RFB recently.
The tally looks weird :)
- 100146 tallies, 100419 msec.
**Tree** -------------------------------- Process: other processes -------------------------------- 5.7% {5724ms} EventSensor>>eventTickler 5.7% {5724ms} Delay>>wait 5.7% {5724ms} primitives -------------------------------- Process: (40) 43725: nil -------------------------------- 94.3% {94695ms} WorldState>>doOneCycleFor: 94.3% {94695ms} WorldState>>doOneCycleNowFor: 93.9% {94293ms} WorldState>>displayWorldSafely: 93.9% {94293ms} PasteUpMorph>>displayWorld 93.9% {94293ms} PasteUpMorph>>privateOuterDisplayWorld 93.9% {94293ms} WorldState>>displayWorld:submorphs: 85.6% {85959ms} WorldState>>drawWorld:submorphs:invalidAreasOn: |85.3% {85657ms} FormCanvas(Canvas)>>fullDrawMorph: | 85.3% {85657ms} FormCanvas(Canvas)>>fullDraw: | 85.3% {85657ms} SystemWindow(Morph)>>fullDrawOn: | 39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder | |39.6% {39766ms} primitives | 34.2% {34343ms} SystemWindow(Morph)>>drawSubmorphsOn: | |34.1% {34243ms} FormCanvas(Canvas)>>fullDrawMorph: | | 34.1% {34243ms} FormCanvas(Canvas)>>fullDraw: | | 34.1% {34243ms} GLViewportMorph(Morph)>>fullDrawOn: | | 33.9% {34042ms} FormCanvas(Canvas)>>drawMorph: | | 33.9% {34042ms} FormCanvas(Canvas)>>draw: | | 33.9% {34042ms} GLViewportMorph>>drawOn: | | 32.8% {32937ms} NBMSAAOffscreenDisplay>>updateForm:bounds: | | 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer | 11.0% {11046ms} FormCanvas(Canvas)>>drawMorph: | 10.9% {10946ms} FormCanvas(Canvas)>>draw: | 10.9% {10946ms} SystemWindow(Morph)>>drawOn: | 10.9% {10946ms} FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle: | 10.8% {10845ms} FormCanvas>>fillRectangle:fillStyle: | 10.8% {10845ms} FormCanvas>>balloonFillRectangle:fillStyle: | 10.8% {10845ms} BalloonCanvas>>fillRectangle:fillStyle: | 10.8% {10845ms} BalloonCanvas>>drawRectangle:color:borderWidth:borderColor: | 10.7% {10745ms} BalloonEngine>>drawRectangle:fill:bor...borderColor:transform: | 10.7% {10745ms} BalloonEngine>>postFlushIfNeeded | 10.7% {10745ms} BalloonEngine>>copyBits | 10.7% {10745ms} BalloonEngine>>copyLoopFaster | 10.7% {10745ms} primitives 8.3% {8335ms} WorldState>>forceDamageToScreen: 8.3% {8335ms} DisplayScreen>>forceDamageToScreen: 8.3% {8335ms} OrderedCollection>>do: **Leaves** 39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer 10.7% {10745ms} BalloonEngine>>copyLoopFaster 8.3% {8335ms} OrderedCollection>>do: 5.7% {5724ms} Delay>>wait
**Memory** old +193,508 bytes young +173,384 bytes used +366,892 bytes free -366,892 bytes
**GCs** full 0 totalling 0ms (0.0% uptime) incr 1331 totalling 356ms (0.0% uptime), avg 0.0ms tenures 2 (avg 665 GCs/tenure) root table 0 overflows
-------- This is weird it shows that it spends 40% of time in SystemWindow(Morph)>>hasRolloverBorder
The actual workload should be concentrated here: | | 32.8% {32937ms} NBMSAAOffscreenDisplay>>updateForm:bounds: | | 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer
but it takes only 1/3 of all time (this is including blitting bits back to system memory).
What is interesting, that if there is no copy to system memory, rendering these simple things (about 60 glyphs with nice AA), takes less than 2% of time:
| 1.6% {689ms} GLViewportMorph>>drawOn:
while most of the time, again spent in #hasRolloverBorder **Leaves** 61.3% {26403ms} SystemWindow(Morph)>>hasRolloverBorder 15.9% {6848ms} BalloonEngine>>copyLoopFaster 12.0% {5169ms} OrderedCollection>>do: 4.7% {2024ms} Delay>>wait
So, it could run 32%/2% ~~ 16 times faster
Levente
In both images, i used:
Display depth 32 Display isLittleEndian true
-- Best regards, Igor Stasenko AKA sig.
On 5/24/2010 1:28 PM, Igor Stasenko wrote:
On 24 May 2010 23:06, Levente Uzonyileves@elte.hu wrote:
On Mon, 24 May 2010, Igor Stasenko wrote:
Btw, i noticed that running it full-screen in pharo is still quite fast and smooth, which makes me wonder, what extra a squeak image does to perform blitting on screen. Something slows things down there.
Did you try the profiler (Extras menu)? I found it pretty useful when I was hacking RFB recently.
The tally looks weird :)
http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/134405....
A real-world case of issue #3.
Cheers, - Andreas
- 100146 tallies, 100419 msec.
**Tree**
Process: other processes
5.7% {5724ms} EventSensor>>eventTickler 5.7% {5724ms} Delay>>wait 5.7% {5724ms} primitives
Process: (40) 43725: nil
94.3% {94695ms} WorldState>>doOneCycleFor: 94.3% {94695ms} WorldState>>doOneCycleNowFor: 93.9% {94293ms} WorldState>>displayWorldSafely: 93.9% {94293ms} PasteUpMorph>>displayWorld 93.9% {94293ms} PasteUpMorph>>privateOuterDisplayWorld 93.9% {94293ms} WorldState>>displayWorld:submorphs: 85.6% {85959ms} WorldState>>drawWorld:submorphs:invalidAreasOn: |85.3% {85657ms} FormCanvas(Canvas)>>fullDrawMorph: | 85.3% {85657ms} FormCanvas(Canvas)>>fullDraw: | 85.3% {85657ms} SystemWindow(Morph)>>fullDrawOn: | 39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder | |39.6% {39766ms} primitives | 34.2% {34343ms} SystemWindow(Morph)>>drawSubmorphsOn: | |34.1% {34243ms} FormCanvas(Canvas)>>fullDrawMorph: | | 34.1% {34243ms} FormCanvas(Canvas)>>fullDraw: | | 34.1% {34243ms} GLViewportMorph(Morph)>>fullDrawOn: | | 33.9% {34042ms} FormCanvas(Canvas)>>drawMorph: | | 33.9% {34042ms} FormCanvas(Canvas)>>draw: | | 33.9% {34042ms} GLViewportMorph>>drawOn: | | 32.8% {32937ms} NBMSAAOffscreenDisplay>>updateForm:bounds: | | 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer | 11.0% {11046ms} FormCanvas(Canvas)>>drawMorph: | 10.9% {10946ms} FormCanvas(Canvas)>>draw: | 10.9% {10946ms} SystemWindow(Morph)>>drawOn: | 10.9% {10946ms} FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle: | 10.8% {10845ms} FormCanvas>>fillRectangle:fillStyle: | 10.8% {10845ms} FormCanvas>>balloonFillRectangle:fillStyle: | 10.8% {10845ms} BalloonCanvas>>fillRectangle:fillStyle: | 10.8% {10845ms} BalloonCanvas>>drawRectangle:color:borderWidth:borderColor: | 10.7% {10745ms} BalloonEngine>>drawRectangle:fill:bor...borderColor:transform: | 10.7% {10745ms} BalloonEngine>>postFlushIfNeeded | 10.7% {10745ms} BalloonEngine>>copyBits | 10.7% {10745ms} BalloonEngine>>copyLoopFaster | 10.7% {10745ms} primitives 8.3% {8335ms} WorldState>>forceDamageToScreen: 8.3% {8335ms} DisplayScreen>>forceDamageToScreen: 8.3% {8335ms} OrderedCollection>>do: **Leaves** 39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer 10.7% {10745ms} BalloonEngine>>copyLoopFaster 8.3% {8335ms} OrderedCollection>>do: 5.7% {5724ms} Delay>>wait
**Memory** old +193,508 bytes young +173,384 bytes used +366,892 bytes free -366,892 bytes
**GCs** full 0 totalling 0ms (0.0% uptime) incr 1331 totalling 356ms (0.0% uptime), avg 0.0ms tenures 2 (avg 665 GCs/tenure) root table 0 overflows
This is weird it shows that it spends 40% of time in SystemWindow(Morph)>>hasRolloverBorder
The actual workload should be concentrated here: | | 32.8% {32937ms} NBMSAAOffscreenDisplay>>updateForm:bounds: | | 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer
but it takes only 1/3 of all time (this is including blitting bits back to system memory).
What is interesting, that if there is no copy to system memory, rendering these simple things (about 60 glyphs with nice AA), takes less than 2% of time:
| 1.6% {689ms} GLViewportMorph>>drawOn:while most of the time, again spent in #hasRolloverBorder **Leaves** 61.3% {26403ms} SystemWindow(Morph)>>hasRolloverBorder 15.9% {6848ms} BalloonEngine>>copyLoopFaster 12.0% {5169ms} OrderedCollection>>do: 4.7% {2024ms} Delay>>wait
So, it could run 32%/2% ~~ 16 times faster
Levente
In both images, i used:
Display depth 32 Display isLittleEndian true
-- Best regards, Igor Stasenko AKA sig.
On 25 May 2010 00:18, Andreas Raab andreas.raab@gmx.de wrote:
On 5/24/2010 1:28 PM, Igor Stasenko wrote:
On 24 May 2010 23:06, Levente Uzonyileves@elte.hu wrote:
On Mon, 24 May 2010, Igor Stasenko wrote:
Btw, i noticed that running it full-screen in pharo is still quite fast and smooth, which makes me wonder, what extra a squeak image does to perform blitting on screen. Something slows things down there.
Did you try the profiler (Extras menu)? I found it pretty useful when I was hacking RFB recently.
The tally looks weird :)
http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/134405....
A real-world case of issue #3.
Oh, i see. So this is actually a time spent to draw a systemwindow background.
Btw, i discovered that openGL driver distributes the load over all 4 cores of my pc.
Cheers, - Andreas
- 100146 tallies, 100419 msec.
**Tree**
Process: other processes
5.7% {5724ms} EventSensor>>eventTickler 5.7% {5724ms} Delay>>wait 5.7% {5724ms} primitives
Process: (40) 43725: nil
94.3% {94695ms} WorldState>>doOneCycleFor: 94.3% {94695ms} WorldState>>doOneCycleNowFor: 93.9% {94293ms} WorldState>>displayWorldSafely: 93.9% {94293ms} PasteUpMorph>>displayWorld 93.9% {94293ms} PasteUpMorph>>privateOuterDisplayWorld 93.9% {94293ms} WorldState>>displayWorld:submorphs: 85.6% {85959ms} WorldState>>drawWorld:submorphs:invalidAreasOn: |85.3% {85657ms} FormCanvas(Canvas)>>fullDrawMorph: | 85.3% {85657ms} FormCanvas(Canvas)>>fullDraw: | 85.3% {85657ms} SystemWindow(Morph)>>fullDrawOn: | 39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder | |39.6% {39766ms} primitives | 34.2% {34343ms} SystemWindow(Morph)>>drawSubmorphsOn: | |34.1% {34243ms} FormCanvas(Canvas)>>fullDrawMorph: | | 34.1% {34243ms} FormCanvas(Canvas)>>fullDraw: | | 34.1% {34243ms} GLViewportMorph(Morph)>>fullDrawOn: | | 33.9% {34042ms} FormCanvas(Canvas)>>drawMorph: | | 33.9% {34042ms} FormCanvas(Canvas)>>draw: | | 33.9% {34042ms} GLViewportMorph>>drawOn: | | 32.8% {32937ms} NBMSAAOffscreenDisplay>>updateForm:bounds: | | 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer | 11.0% {11046ms} FormCanvas(Canvas)>>drawMorph: | 10.9% {10946ms} FormCanvas(Canvas)>>draw: | 10.9% {10946ms} SystemWindow(Morph)>>drawOn: | 10.9% {10946ms} FormCanvas(Canvas)>>fillRectangle:fillStyle:borderStyle: | 10.8% {10845ms} FormCanvas>>fillRectangle:fillStyle: | 10.8% {10845ms} FormCanvas>>balloonFillRectangle:fillStyle: | 10.8% {10845ms} BalloonCanvas>>fillRectangle:fillStyle: | 10.8% {10845ms} BalloonCanvas>>drawRectangle:color:borderWidth:borderColor: | 10.7% {10745ms} BalloonEngine>>drawRectangle:fill:bor...borderColor:transform: | 10.7% {10745ms} BalloonEngine>>postFlushIfNeeded | 10.7% {10745ms} BalloonEngine>>copyBits | 10.7% {10745ms} BalloonEngine>>copyLoopFaster | 10.7% {10745ms} primitives 8.3% {8335ms} WorldState>>forceDamageToScreen: 8.3% {8335ms} DisplayScreen>>forceDamageToScreen: 8.3% {8335ms} OrderedCollection>>do: **Leaves** 39.6% {39766ms} SystemWindow(Morph)>>hasRolloverBorder 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer 10.7% {10745ms} BalloonEngine>>copyLoopFaster 8.3% {8335ms} OrderedCollection>>do: 5.7% {5724ms} Delay>>wait
**Memory** old +193,508 bytes young +173,384 bytes used +366,892 bytes free -366,892 bytes
**GCs** full 0 totalling 0ms (0.0% uptime) incr 1331 totalling 356ms (0.0% uptime), avg 0.0ms tenures 2 (avg 665 GCs/tenure) root table 0 overflows
This is weird it shows that it spends 40% of time in SystemWindow(Morph)>>hasRolloverBorder
The actual workload should be concentrated here: | | 32.8% {32937ms} NBMSAAOffscreenDisplay>>updateForm:bounds: | | 32.7% {32837ms} NBGLFrameBuffer>>bindAsDrawBuffer
but it takes only 1/3 of all time (this is including blitting bits back to system memory).
What is interesting, that if there is no copy to system memory, rendering these simple things (about 60 glyphs with nice AA), takes less than 2% of time:
| 1.6% {689ms} GLViewportMorph>>drawOn:
while most of the time, again spent in #hasRolloverBorder **Leaves** 61.3% {26403ms} SystemWindow(Morph)>>hasRolloverBorder 15.9% {6848ms} BalloonEngine>>copyLoopFaster 12.0% {5169ms} OrderedCollection>>do: 4.7% {2024ms} Delay>>wait
So, it could run 32%/2% ~~ 16 times faster
Levente
In both images, i used:
Display depth 32 Display isLittleEndian true
-- Best regards, Igor Stasenko AKA sig.
For GLViewportMorph, it takes ~ 9ms to render a frame + blit results to system memory:
| canv | canv := Display getCanvas. [ 1000 timesRepeat: [ self drawOn: canv ] ] timeToRun
9714
if i disabling blitting to system memory, then the above loop takes 789 ms < 1 ms per frame
Drawing a system window morph with 600@400 extent (an outer morph , which is a little bit bigger than GLViewportMorph which sits inside of it): 4327
~ 4ms per frame (its just fills the rectangle with constant color)
For the same window on pharo it takes just 1393 ms.
Scaling a system window (along with GLViewportMorph) to 1200@800
GLViewportMorph + blit to system memory - 24611 ms GLViewportMorph w/o blit to system memory - 754 ms SystemWindow - 12351
so, with increase of drawable area by 4x factor, rendering times not changes. blitting to system memory is 2.5 slower and drawing a rectangle is 4x slower - a worst result showing an exact linear dependency from covered area.
On Mon, 24 May 2010 13:07:20 -0500, Igor Stasenko siguctua@gmail.com wrote:
On 24 May 2010 20:20, Kevin Kelley kevin@kelleysoft.com wrote:
The animation loop's
running fast and smooth, and doesn't seem to be giving much cpu load.
Well, actually it does :)
Okay, so the memcopy's are taking up a little bit of time; still, the big win so far is having the gpu render the font glyph based on just the outline data, you're getting scalable fonts on the fly effectively for free. This is seriously cool.
That GPU gems link ( http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html ) referenced in your code is a good explanation. Shaders kind of break my brain, I'm glad to see this one in and working.
Cheers, Kevin Kelley
On 25 May 2010 02:13, Kevin Kelley kevin@kelleysoft.com wrote:
On Mon, 24 May 2010 13:07:20 -0500, Igor Stasenko siguctua@gmail.com wrote:
On 24 May 2010 20:20, Kevin Kelley kevin@kelleysoft.com wrote:
The animation loop's
running fast and smooth, and doesn't seem to be giving much cpu load.
Well, actually it does :)
Okay, so the memcopy's are taking up a little bit of time; still, the big win so far is having the gpu render the font glyph based on just the outline data, you're getting scalable fonts on the fly effectively for free. This is seriously cool.
That GPU gems link ( http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html ) referenced in your code is a good explanation. Shaders kind of break my brain, I'm glad to see this one in and working.
Every hardware is quite stupid and primitive thing. Once you got the basics, the rest is just a piece of cake. Btw, this is my first shader routine i ever written :)
Cheers, Kevin Kelley
On 5/24/2010 7:03 AM, Igor Stasenko wrote:
- first, you need to have VM with NativeBoost plugin + NativeBoost
loaded into an image (see http://code.google.com/p/nativeboost/wiki/Installation for instructions)
The page doesn't have any information on how to download the binary plugin. Do I really need to rebuild it from sources?
- then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL
in following order:
- NBOpenGL-Core
- NBOpenGL-Win
This fails with the following error:
--------------------------------------------------------------
This package depends on the following classes: NBWinTypes NBWinConstants You must resolve these dependencies before you will be able to load these definitions: GLPixelFormatDescriptor .... --------------------------------------------------------------
i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were released recently, and it seems works ok. on squeak/trunk it should also work without problems.
I've used 4.1 but I don't think this should matter for the above, no?
Now, if everything went right, then we're ready to run a demo:
GLViewportMorph new "useOwnForm: true;" openInWorld
And ultimately this fails too due to GLPixelFormatDescriptor not loaded.
Any ideas what's wrong with NBWinTypes and NBWinConstants?
Cheers, - Andreas
On 25 May 2010 03:47, Andreas Raab andreas.raab@gmx.de wrote:
On 5/24/2010 7:03 AM, Igor Stasenko wrote:
- first, you need to have VM with NativeBoost plugin + NativeBoost
loaded into an image (see http://code.google.com/p/nativeboost/wiki/Installation for instructions)
The page doesn't have any information on how to download the binary plugin. Do I really need to rebuild it from sources?
You can just take a prebuilt VM from http://code.google.com/p/nativeboost/downloads/list
- then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL
in following order:
- NBOpenGL-Core
- NBOpenGL-Win
This fails with the following error:
This package depends on the following classes: NBWinTypes NBWinConstants You must resolve these dependencies before you will be able to load these definitions: GLPixelFormatDescriptor ....
i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were released recently, and it seems works ok. on squeak/trunk it should also work without problems.
I've used 4.1 but I don't think this should matter for the above, no?
Yes, i developped it in 4.1 . So, it should work at least there :)
Now, if everything went right, then we're ready to run a demo:
GLViewportMorph new "useOwnForm: true;" openInWorld
And ultimately this fails too due to GLPixelFormatDescriptor not loaded.
Any ideas what's wrong with NBWinTypes and NBWinConstants?
You need to install a NativeBoost first. NBOpenGL is separate thing which using a NativeBoost.
Cheers, - Andreas
On 5/24/2010 6:17 PM, Igor Stasenko wrote:
You can just take a prebuilt VM from http://code.google.com/p/nativeboost/downloads/list
Okay, good, that's what I did. FWIW, there's an installation bug for NB. When you run "NBInstaller install" *without* the plugin, it will fail to determine the platform id and will not install the Windows stuff. That's what caused my later problems. I would recommend installing *all* platform examples regardless of actual platform id to avoid issues like these. I find Unix examples just as instructive as Windows examples ;-)
However, even after doing that, it fails to run. It blows up in NBGLFrameBuffer>>checkStatus which needs to use "self CLASS bindingOf: sym" to resolve the code. When I fix that it gets me to an GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT and that's where I'm at right now. In case it helps, the offending code is in
NBMSAAOffscreenDisplay>>initDisplay "perform a usual initializations" renderFBO := NBGLFrameBuffer new initialize: self gl extent: extent. renderFBO createMultisampleAttachments: 4. renderFBO checkStatus. "... more stuff ..."
Any ideas what to look for? I have an ATI Mobility Radeon HD 4330 running Windows 7.
Cheers, - Andreas
On 25 May 2010 05:57, Andreas Raab andreas.raab@gmx.de wrote:
On 5/24/2010 6:17 PM, Igor Stasenko wrote:
You can just take a prebuilt VM from http://code.google.com/p/nativeboost/downloads/list
Okay, good, that's what I did. FWIW, there's an installation bug for NB. When you run "NBInstaller install" *without* the plugin, it will fail to determine the platform id and will not install the Windows stuff. That's what caused my later problems. I would recommend installing *all* platform examples regardless of actual platform id to avoid issues like these. I find Unix examples just as instructive as Windows examples ;-)
Oh give it a time :)
However, even after doing that, it fails to run. It blows up in NBGLFrameBuffer>>checkStatus which needs to use "self CLASS bindingOf: sym" to resolve the code.
Thanks for finding it! I never run into that code, that's why it wasn't tested. :)
When I fix that it gets me to an GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT and that's where I'm at right now. In case it helps, the offending code is in
NBMSAAOffscreenDisplay>>initDisplay "perform a usual initializations" renderFBO := NBGLFrameBuffer new initialize: self gl extent: extent. renderFBO createMultisampleAttachments: 4. renderFBO checkStatus. "... more stuff ..."
Any ideas what to look for? I have an ATI Mobility Radeon HD 4330 running Windows 7.
It either your card doesn't supports MSAA, or driver don't likes the FBO configuration which i provided.
Check that
NBWinContextState new pixelFormatInfo extensions includes: #GL_EXT_packed_depth_stencil
i suspect this is your problem, because you're unlucky owner of wrong hardware/drivers :) http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Numb...
Also, you could try running with MSAA turned off, go to NBGLDisplay class>>pickImplementation and put comment around " ^ NBMSAAOffscreenDisplay "
Cheers, - Andreas
On 5/24/2010 8:32 PM, Igor Stasenko wrote:
It either your card doesn't supports MSAA, or driver don't likes the FBO configuration which i provided.
I think the error code indicates a problem with the FBO configuration. For example, check out the restrictions on OpenGL ES for this stuff:
http://www.khronos.org/opengles/sdk/doc/man/glCheckFramebufferStatus.xml
It seems as if one needs to be very picky for getting the 'right' configuration on all platforms. Is there an enumeration by any chance that allows one to pick the proper (supported) configuration?
Check that
NBWinContextState new pixelFormatInfo extensions includes: #GL_EXT_packed_depth_stencil
It's there.
Also, you could try running with MSAA turned off, go to NBGLDisplay class>>pickImplementation and put comment around " ^ NBMSAAOffscreenDisplay "
That appears to work but the glyphs are drawn "improperly" (see screenshot). I'm not sure if that's the way they're intended to be rendered or if that's an artifact of running a different configuration.
Cheers, - Andreas
On 25 May 2010 07:22, Andreas Raab andreas.raab@gmx.de wrote:
On 5/24/2010 8:32 PM, Igor Stasenko wrote:
It either your card doesn't supports MSAA, or driver don't likes the FBO configuration which i provided.
I think the error code indicates a problem with the FBO configuration. For example, check out the restrictions on OpenGL ES for this stuff:
http://www.khronos.org/opengles/sdk/doc/man/glCheckFramebufferStatus.xml
It seems as if one needs to be very picky for getting the 'right' configuration on all platforms. Is there an enumeration by any chance that allows one to pick the proper (supported) configuration?
Yeah.. this is a black voodoo. For instance, my video card rejects FBO with color+stencil only (that's all what i need). You may try various things in NBGLFrameBuffer>>createMultisampleAttachments: numSamples or in NBGLFrameBuffer>>createAttachments
Check that
NBWinContextState new pixelFormatInfo extensions includes: #GL_EXT_packed_depth_stencil
It's there.
Also, you could try running with MSAA turned off, go to NBGLDisplay class>>pickImplementation and put comment around " ^ NBMSAAOffscreenDisplay "
That appears to work but the glyphs are drawn "improperly" (see screenshot). I'm not sure if that's the way they're intended to be rendered or if that's an artifact of running a different configuration.
Yes, its improper. It looks like that when you don't have a stencil buffer (or have it disabled). Your screenshot also shows that you got my little shader running properly which is used to render quad beziers. And this is more important than stencil (i think it could be solved by picking different FBO attachment formats).
Cheers, - Andreas
It works fine for me (Geforce 8800GTS).
Maybe Andreas needs updated drivers? That's helped some people with similar problems: http://www.gamedev.net/community/forums/topic.asp?topic_id=568410
Your GPU is way newer than in the following post, but maybe try power-of-two window dimensions: http://forums.amd.com/devforum/messageview.cfm?catid=392&threadid=115093...
Cheers, Josh
On May 24, 2010, at 9:48 PM, Igor Stasenko wrote:
On 25 May 2010 07:22, Andreas Raab andreas.raab@gmx.de wrote:
On 5/24/2010 8:32 PM, Igor Stasenko wrote:
It either your card doesn't supports MSAA, or driver don't likes the FBO configuration which i provided.
I think the error code indicates a problem with the FBO configuration. For example, check out the restrictions on OpenGL ES for this stuff:
http://www.khronos.org/opengles/sdk/doc/man/glCheckFramebufferStatus.xml
It seems as if one needs to be very picky for getting the 'right' configuration on all platforms. Is there an enumeration by any chance that allows one to pick the proper (supported) configuration?
Yeah.. this is a black voodoo. For instance, my video card rejects FBO with color+stencil only (that's all what i need). You may try various things in NBGLFrameBuffer>>createMultisampleAttachments: numSamples or in NBGLFrameBuffer>>createAttachments
Check that
NBWinContextState new pixelFormatInfo extensions includes: #GL_EXT_packed_depth_stencil
It's there.
Also, you could try running with MSAA turned off, go to NBGLDisplay class>>pickImplementation and put comment around " ^ NBMSAAOffscreenDisplay "
That appears to work but the glyphs are drawn "improperly" (see screenshot). I'm not sure if that's the way they're intended to be rendered or if that's an artifact of running a different configuration.
Yes, its improper. It looks like that when you don't have a stencil buffer (or have it disabled). Your screenshot also shows that you got my little shader running properly which is used to render quad beziers. And this is more important than stencil (i think it could be solved by picking different FBO attachment formats).
Cheers,
- Andreas
-- Best regards, Igor Stasenko AKA sig.
<GL viewport.png>
On 29 May 2010 09:41, Josh Gargus josh@schwa.ca wrote:
It works fine for me (Geforce 8800GTS).
Maybe Andreas needs updated drivers? That's helped some people with similar problems: http://www.gamedev.net/community/forums/topic.asp?topic_id=568410
Your GPU is way newer than in the following post, but maybe try power-of-two window dimensions: http://forums.amd.com/devforum/messageview.cfm?catid=392&threadid=115093...
Yes, its a long-standing problem with ATI drivers (i hope not with cards). Henrik also reported that it unable to create MSAA FBO on his Radeopn HD4870.
I wonder if ATI cards/drivers ever support depth+stencil multisampling in FBOs. Actually, i could use back buffer for rendering instead of FBO.
Cheers, Josh
On May 24, 2010, at 9:48 PM, Igor Stasenko wrote:
On 25 May 2010 07:22, Andreas Raab andreas.raab@gmx.de wrote:
On 5/24/2010 8:32 PM, Igor Stasenko wrote:
It either your card doesn't supports MSAA, or driver don't likes the FBO configuration which i provided.
I think the error code indicates a problem with the FBO configuration. For example, check out the restrictions on OpenGL ES for this stuff:
http://www.khronos.org/opengles/sdk/doc/man/glCheckFramebufferStatus.xml
It seems as if one needs to be very picky for getting the 'right' configuration on all platforms. Is there an enumeration by any chance that allows one to pick the proper (supported) configuration?
Yeah.. this is a black voodoo. For instance, my video card rejects FBO with color+stencil only (that's all what i need). You may try various things in NBGLFrameBuffer>>createMultisampleAttachments: numSamples or in NBGLFrameBuffer>>createAttachments
Check that
NBWinContextState new pixelFormatInfo extensions includes: #GL_EXT_packed_depth_stencil
It's there.
Also, you could try running with MSAA turned off, go to NBGLDisplay class>>pickImplementation and put comment around " ^ NBMSAAOffscreenDisplay "
That appears to work but the glyphs are drawn "improperly" (see screenshot). I'm not sure if that's the way they're intended to be rendered or if that's an artifact of running a different configuration.
Yes, its improper. It looks like that when you don't have a stencil buffer (or have it disabled). Your screenshot also shows that you got my little shader running properly which is used to render quad beziers. And this is more important than stencil (i think it could be solved by picking different FBO attachment formats).
Cheers, - Andreas
-- Best regards, Igor Stasenko AKA sig.
<GL viewport.png>
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Igor Stasenko -
Josh Gargus -
Kevin Kelley -
Levente Uzonyi