Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - bigsofty

Pages: [1] 2 3 ... 171
Great news, thanks Gernot!  :good:

Lol, you had me going for a bit, when I stuck in 99 and it looked like it worked, a quick...  :O =D :o :(

Use screenID% = 99 .... then it works

Unfortunately CREATESCREEN ID%, ID% is limited from 0 to 31, so going above 31, is the same as -1, which is the backbuffer, so 99, is basically just normal rendering to the screen, not buffering it to a sprite. This can be illustrated by adding a CLEARSCREEN before the first  X_MAKE_2D. If it was copied properly via an FBO it should still reside within the spriteID% which unfortunately it doesn't, and drawing the sprite should show the screen but as it was  USESCREEN  99 (same as -1) , its simply drawing  to the screen and not drawing/buffering it.  :( TBH I'm kinda surprised it did not throw an error.

Its good to know that this was working at some point (version) so maybe its an easy fix for Gernot?

That's interesting, so earlier versions don't have this behaviour?  :blink:

Changing the DRAWSPRITE line to assume that the dimensions have increased to the next ^2 (640=1024, 480=512) and adjusting the image position to compensate for the increased size, you can remove the XY discrepancy. And it fixes its position(although not the overall scale) accordingly, this kinda proves that the image has been resized upwards to the power of 2.

Code: GLBasic [Select]
                DRAWSPRITE spriteID%, -(1024 - 640)/2, -(512 - 480)/2
//              DRAWSPRITE spriteID%, 0,0

Its kinda driving me nuts because I have full screen post-processing shaders working but GLBasic is internally messing the final result up unfortunately by changing the scale before I can access the FBO sprite.

Thanks again Erico, some nice comparison pictures there!  :good:

Purely guessing here but I don't think it has anything to do with 3D coordinates, or the camera being moved or even what you are trying to render. I think USESCREEN  takes a snapshot of the screen and fits it on a texture that is not the same size of the screen, even though I requested it to do so. So when you try and paste the snapshot back onto the screen, it no longer aligns. I think it only does this if your screen dimensions are not an even power of 2. Which used to be a pre-requisite for fast texture access on older handheld devices. So I think it may be a feature from way back which now hinders desktop platforms today.

BTW you should see a message with in debug mode?

Edit: I had a quick look at the GLBasic FBO buffers creation code and suggested a fix...

Thank for trying Erico, did the 3D cursor move when you pressed a key?

Also, did you get a "FBOs supported" in the debug console window?

A weird thing I did discover is that if I make the resolution to an even power of 2(256x256, 512x512, 1024x1024 etc.) it works fine. Which makes me think it could be something to do with the allocated texture size for the FBOs buffers?  :S

OK, all I want to do is render my 3D scene to a texture and dump it back onto a 2D screen. But when I do, the origin of the 3D camera seems to jump to the right(or the grabbed texture dimensions are getting messed up).

It's one of those situations that you know something is wrong but cant see the reason why?  :blink:

Please run this snippet at 640x480 windowed please and tell me if you get the same result?

Code: GLBasic [Select]
SETCURRENTDIR("Media") // go to media files

GLOBAL screenID%, spriteID%
GLOBAL screenWidth%, screenHeight%
GETSCREENSIZE screenWidth%, screenHeight% // 640,480, windowed
screenID% = 0
spriteID% = GENSPRITE()

DEBUG IIF( PLATFORMINFO$("GLEX:glBindFramebufferEXT")=1, "FBOs supported\n", "FBOs not supported\n" )

CREATESCREEN screenID%, spriteID%, screenWidth%, screenHeight%


                USESCREEN screenID%
                CLEARSCREEN RGB( 44, 44, 44 )
                X_MAKE3D 1, 1000, 75
                X_CAMERA 0,0,-100, 0,0,0
                X_DRAWAXES 0,0,0
                USESCREEN -1

                DRAWSPRITE spriteID%, 0, 0
                PRINT "Rendering to texture", 0,0

                CLEARSCREEN RGB( 44, 44, 44 )
                X_MAKE3D 1, 1000, 75
                X_CAMERA 0,0,-100, 0,0,0
                X_DRAWAXES 0,0,0

                PRINT "Not rendering to texture", 0,0


Oh, as a side note, is anyone getting the message "FBOs supported" in the debug window?

Well done Mr Plow, I know what a PITA this stuff can be!  :good:

Announcements / Re: Book
« on: 2019-Nov-11 »
Amazon call me impressed! Good luck with the release Mr Plow.  :good:

Off Topic / Re: Voxels are the future!
« on: 2019-Nov-03 »
I would imagine the voxels are held and manipulated on the GPU via compute shaders?

Well spotted, thank for the tip!  :good:

GLBasic - en / Re: GLBasic
« on: 2019-Oct-13 »
Good to hear Gernot!  :booze:

Announcements / Re: Server change
« on: 2019-Sep-21 »
Will the current sites post be kept? Lots of handy stuff on here.  :P

Announcements / Re: TH_AVOCADO MAYHEM
« on: 2019-Aug-29 »
+1 for a point and click. My daughter (who’s 10) recently discovered point and click adventures on Steam, is obsessed with Thimbleweed Park. To us they may seem a bit old hat but to this generation they’re new and fresh.

Congrats on the release Erico too!   :good:

Off Topic / Re: Voxels are the future!
« on: 2019-Aug-27 »
Yeah, the guys who covering this is a bit bonkers :S but the tech is very impressive. It does have proper ray traced voxels (not meshes made out of cubes). I am totally dumbfounded how he managed to attach a physics engine on this?!? Your basically looking at a 3 dimentional array of 10cm cubes. Even the smoke and fire, particle systems, seem to be aware of the individual voxels. I pretty sure your looking at millions of voxels here, how the hell is this running in real time?

Love it when a coder does somthing that produces that ,WTF?!?, moment.

Pages: [1] 2 3 ... 171