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 ... 172
1
Announcements / Re: Red Wizard Island
« on: 2020-Jan-26 »
Testing endboss

https://youtu.be/yB8ajfIRsNM

https://www.redwizardisland.com

Looks great!   :good:

Possibly add some hissing sound FX?

2
GLBasic - en / Re: Multi istances
« on: 2020-Jan-22 »
For me, from the Steam version, I first launch the Steam version from the Steam app and then run the instances directly from the Steam "common\GLBasic_SDK" folder.

That is for instances, I navigate to "C:\Program Files (x86)\Steam\steamapps\common\GLBasic_SDK" and then run "GLBasicEditor.exe"

Pretty untested though as I don't use instances myself.

Oh, and I would definitely not close the original Steam launched version, before any instances have been closed first.

3
Announcements / Re: Grave Digger Ex
« on: 2020-Jan-07 »
I like it, the gameplay seems to be quite unusual, semi-puzzle/action. If you could sync up music to the movement, there’s a definite Crypt Of The Necrodancer vibe here.

4
Off Topic / Re: Happy New Year!
« on: 2020-Jan-01 »
Thanks SnooPI, happy new year guys!  :booze:

5
Off Topic / Merry Christmas!
« on: 2019-Dec-24 »
It's that time of year, have a good one guys!


6
Announcements / Re: 2600 shooter
« on: 2019-Dec-24 »
Smart move, Taito has trademarked every one of the original invaders design separately.  :S

I like the top ones design, reminds me of Space Panic another great arcade game from that era... now I am really showing my age!  :D

7
Announcements / Re: 2600 shooter
« on: 2019-Dec-24 »
Looks pretty authentic, well done!  :good:

8
Great news, thanks Gernot!  :good:

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

10
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?

11
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.

12
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... http://www.glbasic.com/forum/index.php?topic=11363.msg99945#msg99945

13
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


14
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%

   WHILE TRUE

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

X_MAKE2D
DRAWSPRITE spriteID%, 0, 0
PRINT "Rendering to texture", 0,0
      SHOWSCREEN
      KEYWAIT

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

X_MAKE2D
PRINT "Not rendering to texture", 0,0
      SHOWSCREEN
      KEYWAIT

   WEND

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

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

Pages: [1] 2 3 ... 172