Hello, You should start trying to use Woden and Woden-Roassal. Everything of Roassal 3D will be moved to Woden. http://smalltalkhub.com/#!/~ronsaldo/Woden . To install it you only have to run this script:
Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) loadBleedingEdge In Woden I have many bugs to fix, which I havent because I have been busy the last month making the new FFI. I have still problems with NBOpenGL with an ATI Radeon HD 4250 > Graphic card What graphic driver do you have? AMD stopped providing support to the graphics cards older than the HD 5xxx, If i remember it correctly. I guess that you are using the open source drivers. Greetings, Ronie 2014-10-12 14:03 GMT-03:00 Nicolai Hess <[email protected]>: > like described here > http://forum.world.st/Roassal-3D-empty-windows-td4749249.html > and here > http://forum.world.st/NBOpenGL-on-Windows-td4749309.html > > I have still problems with NBOpenGL with an ATI Radeon HD 4250 > Graphic card > > No way to get it to work on linux (dont' know why). > > On windows I had the issue that the rendering only happens in > the upper window corner (rendering only happens within the > initial morph/framebuffer bounds). > > I finally solved this issue by reattaching the renderbuffers after every > resize. > ( in NBGLFrameBuffer>>#resize: > I call > self bind > and > for all attachments I call #resize: and #attachTo:as: > (I had to change the attachments set to store the attachment type as well)) > > Now my question is, is it a bug in ATIs opengl implementation > Or are all other users just lucky, that it works for them? > Or it is just uncommon to work with framebuffer objects this way? > Don't know if my solution just works now, but is otherwise wrong > or resuls in leaks or other side effects. > > (Actually there are tons of examples and tutorials online about > framebuffer objects and render-to-texture, but none I found covers the case > of a changed framebuffer size) > > Anyone has some expert knowledge on using framebuffers for > render-to-texture > where this target texture may change its size? > Anyone working with NBOpenGL and hasn't this issue can tell me > which Grahic card he uses? > Or anyone knows something about bugs in ATIs OpenGL driver which > may be responsible for this behavior? > (I read about another bug with render-to-texture but that one only > happened for NVIDIA cards) > > thanks in advance > Nicolai > > (btw in NBGLCurveRenderer there is still a problem with > NBGLFragmentProgramARB vs NBGLFragmentProgram. > All this with Pharo3.0 Latest update: #30858 latest NBOpenGL image > from Pharo Contribution Jenkins) > > > >
