Alternative to FastExt?

Blitz3D Forums/Blitz3D Programming/Alternative to FastExt?

Cubed Inc.(Posted 2015) [#1]
A couple years back, when I still had my Windows 7 laptop, I purchased FastExt to produce real-time shadow effects. When I 'upgraded' to Windows 8, I discovered that FastExt doesn't support the system; the creator(s) of the extension are apparently dead (figuratively speaking, of course), as the website hasn't been updated in about five years.

The only real effect I'm looking to produce are dynamic shadows. Does anyone know any good extensions for Blitz3d that can produce such effects on Windows 8? I'm experimenting with a cell-shaded art-style akin to Jet Set Radio, and dynamic character shadows would really complete the effect (I plan on baking shadows into the game environments via Blender.)


RemiD(Posted 2015) [#2]
If your casters can be low tris meshes (no transparent textures), and if they can be closed meshes (=you can't see any backfaces), and if you don't use Blitz3d terrains, and if for animated meshes you can use bodyparts/vehicleparts attached to joints instead of a skinned mesh, and if you have only one light in the scene/per area, DSS can be a solution, it seems to work on Windows 8. (but there are glitches on too old computers or on low end computers like some netbooks...)

I have added some improvements, i may share the code if somebody is interested...


Rroff(Posted 2015) [#3]
You can use the last version of B3D that works with FastExt and fix the couple of issues the newer patches solve with your own code and/or a dll to fix the windows 8 slowdown issue. (Though not sure about other Windows 8 issues that might exist).


RGR(Posted 2015) [#4]
On first sight it looks as if it has to do with the Blitz Version - but it hasn't

I tried all versions from 1108 down to 196 - there is not one which works reliable on different OSs on newer computers (not older than 4 years) when FastExt is used.
They run inside the IDE on all systems (that's the curious side of it) - but making an exe running it on Systems which have no Blitz3D installed (which is the usual configuration a normal gamer has) you get either MAVs or Userlib not found or are lucky and it runs ... the problem is not even solved with installing an older DX7 Version (which most people won't do anyway fearing it messes their running system)

It is a graphics card driver problem as it seems. Even without FastExt the problems rise ...

Off Topic ...

Some days ago I made changes in my NVidia settings - because I wanted to find out if I can *repair* a windowed problem with one of my blitz programs - which runs superb in fullscreen 1920x1080x32 on XP, Vista, Win 7, many Win 8.1 afaik, but not in a borderless window of any size ... although the framerate is stable at 60 FPS - there's time for 100 times more operations which are actually done each frame - but still there are visible (lags) lerks (? don't know a better translation) ...
I must add - only on a quite new Win 8.1 Laptop I have it works in both modes highest resolution without any visible problem - no lerks at all. But on a high end gaming system of my son, Win 8.1 it lerks fullscreen and windowed ... that's what made us serching for the reason ...

I assumed I could find out more about it, making NVidia settings changes on my Win 7 Pro System ...
After only 3 changes the Program produced a MAV ... running it in Debug mode it showed that it stops at Flip() ... trying some easy examples from the docs it showed again that each test stopped at Flip()
How can changing filtering, prerendering, etc. in the NVidia settings stop working Flip() in Blitz3D completely? I don't know - but it does!

I made a reset in the NVidia Settings and Flip() worked again.

Back to topic: That's what makes me sure that it has nothing to do with the Blitz Version - but is a graphics driver matter - which coincidentically occured together with a Blitz Version change ... but was the actual cause.
So (not meant honest but with a winking eye) you probably would have success not changing the Blitz Version, but using a 5 year old graphics card driver ...)

Well ... maybe we should face it ... the time for Blitz3D is running out ... slowly but unstoppable ...


RemiD(Posted 2015) [#5]
@RGR>>What is the structure of your mainloop ?

Personally i use :
MainLoopTimer = CreateTimer(20)
While( State <> true )
 
 Setbuffer(Backbuffer())
 Renderworld()

 DrawImage()
 Text()

 WaitTimer(MainLoopTimer)
 Flip(1)

wend


One thing that i have never seen anyone talk about is why most of you don't put setbuffer(backbuffer()) before renderworld()... Because as i understand it, renderworld() converts the meshes, textures, animations, lighting, of the 3d scene into the pixels of an image and puts it in the activebuffer, then flip() puts the activebuffer in the frontbuffer and displays it to the user.
But if the activebuffer is not set to be the backbuffer, how renderworld() is supposed to know in which buffer to put the image of the render and what will be flipped to the frontbuffer ?
So except if renderworld() automatically sets the activebuffer to be the backbuffer, i think that it is important to put Setbuffer(backbuffer()) before renderworld().
A bad mainloop structure may produce weird results with some graphic cards...


Rroff(Posted 2015) [#6]
I use SetBuffer BackBuffer() at the graphics init function then after that it should be done via good housekeeping inside your main code i.e. use of:

oldbuffer = GraphicsBuffer()
...
...
...
SetBuffer oldbuffer

Inside functions that might manipulate the graphics buffer.

It is something I notice a lot with other people's code though a lot seem to leave the buffer stuff to chance :S

Your post has given me a thought about a shadow system I was playing with - it might be possible to use renderworld in that way to bypass using copyrect for scrapes of the render buffer for something and give a decent performance increase.


RemiD(Posted 2015) [#7]
Writing SetBuffer(BackBuffer()) after Graphics3d() is enough if you never use imagebuffer() or texturebuffer(), but i often do.

Also even if you use SetBuffer(Backbuffer()) after Graphics3d(), the program is in the backbuffer, then it reaches the mainloop, then flip(), then it is in the frontbuffer, then except if renderworld() automatically sets the activebuffer to backbuffer, the program will draw alternatively in the backbuffer or in the frontbuffer... You may not notice it because of many frames drawn per seconds, but it is not correct...

But maybe renderworld() sets the activebuffer to backbuffer, and in this case, all that i have said is not important to consider...


RGR(Posted 2015) [#8]
Well, now this thread got even more off topic ;-)

I may have not found the right words to make the point clear. What I wanted to say is: make some trivial settings in the NVidia settings panel ... mine is in German, so it would not help to explain it further without spending time to get the english equivalents ... and you may notice that things happen to your Blitz program you never would expect. Settings which work for 1000s of games bring your Blitz3D program to crash.
In the case I mentioned above the driver does not accept Flip() and crashes the program with a MAV ...
Obviously because the driver does not understand what the Blitz Program wants to tell ... its outdated ...

@RemiD - you are obviously here for about 4 years now - I am here 12 years - and you can be sure that I also know something about the program structure and backbuffer and the order what shall be in a loop to make a 3D Program run.

To discuss Backbuffer and Flip() and all that is of no use, if the problem went outside the capabilities of Blitz3D due to changes in Hardware and Graphics Drivers during the last years - while Blitz3D and its third party Addons got not adapted to these changes ...

Going even more off topic again ...
Still hoping Nuclear Basic will fill the hole in the very near future - it got interrupted - but is back on a good way again.
There are not many alternatives leaving Blitz without changing your programming style completely - especially if you have written over 2000 Functions and developed a programming system around Blitz which makes programming in Blitz3D easy and comfortable ... that's why I am still around ... ;-)
Although I know that I should better now than later port these Functions to another Language ...

Anyway. I don't want to bore you with my thoughts ... that's why I stop here.


Rick Nasher(Posted 2015) [#9]
Anybody can confirm RGR's findings about Blitz3d under Win8.x?

Seems pretty important stuff if goes for everyone, cos that would mean we're programming on shaky ground, that can't be repaired by the win8.x slowdown/fastext fixes.
I myself can't test: no Win8.x on my system.

@RGR: Does this only occure when using Fastext or also in plain vanilla Blitz3d?

@RemiD: yup, of course interested in seeing your improvements to DSS.


RemiD(Posted 2015) [#10]
I have done several tests on a computer with Windows 8 and i have not seen any problems, see : http://www.blitzbasic.co.nz/Community/posts.php?topic=102561

Not sure if it works the same on Windows 8.1...



In the case I mentioned above the driver does not accept Flip() and crashes the program with a MAV ...
Obviously because the driver does not understand what the Blitz Program wants to tell


What RGR is saying is that some graphic cards don't like the flip() function and this provokes a MAV.
@RGR>>Have you tried to draw directly in the frontbuffer and not use the backbuffer and the flip() function ?


RemiD(Posted 2015) [#11]

Have you tried to draw directly in the frontbuffer and not use the backbuffer and the flip() function ?


answer : It does not seem to work, so this probably means that renderworld() sets the activebuffer to the backbuffer.

But maybe we can not have to use the flip() function by doing a copyrect from the backbuffer to the frontbuffer ? (after renderworld, drawimage, text)


RemiD(Posted 2015) [#12]

maybe we can not have to use the flip() function by doing a copyrect from the backbuffer to the frontbuffer ? (after renderworld, drawimage, text)


answer : yes it works... You may want to try this RGR, maybe this can help you to make your games work with these graphic cards...


RGR(Posted 2015) [#13]
@RemiD - Concerning the Flip()
After my own program failed at Flip(), first I did was to check if it was my Error ... So I was only using simple Examples from the Documentation.
i. e. CreateSphere ( [segments][,parent] )
; CreateSphere Example
; --------------------

Graphics3D 1920,1080,32,2
SetBuffer BackBuffer()

camera=CreateCamera()

light=CreateLight()
RotateEntity light,90,0,0

; Create sphere
sphere=CreateSphere()

PositionEntity sphere,0,0,5

While Not KeyDown( 1 )
RenderWorld
Flip()
Wend

End


With different Resolutions, Modes and Flip(True) and Flip(False) ... MAV

Worked again after I made a Reset to standard NVidia settings - some *hand made* changes in the NVidia Panel and the MAV Message appears ...

@Rick and all
Why I am quite sure that time runs out with every update of Hardware, OS and Graphics Drivers.
The Program I wrote and where the lerks are visible so obvious ...
I work with 2 Monitors and I checked the CPU performance with Taskmanager on the second Monitor while running the Program in Highest Resolution on the other.
In Fullscreen the CPU is at max 2 % - actual it is not really visible if it is normal background activity or my program.
In Windowed mode one of the CPUs is always between 80 and 100 % (what seems to cause the lerk) and the others are at 1 - 2 % as usual
I spent hours to try to find solutions ... no success ... it seems that on my 4 systems I tried it on it switches from Hardware Acceleration to Software Rendering when in Windowed Mode ... I did not find a way to patch this - so ideas are welcome.
Why else is it that there's such a difference between Fullscreen and Windowed Mode on my Win 7 System? Why is it lerking on a Highend Gaming System with Win 8.1?
Blitz3D got not updated since many years, that's why it is as it is, I guess.

I may load up a cut version as demo this week if possible (don't nail me on that - it's quite an effort to eliminate Pre-Registration, Online Highscore, etc.) ... so it is really a maybe ...


RemiD(Posted 2015) [#14]

Worked again after I made a Reset to standard NVidia settings


Good, if i were you i would not be afraid about this if there is a way to fix it. We all know that it is impossible to make a program compatible and fast enough on all computers, but if the program is compatible and fast enough on most target computers, i think it is good enough.



In Fullscreen the CPU is at max 2 % - actual it is not really visible if it is normal background activity or my program.
In Windowed mode one of the CPUs is always between 80 and 100 % (what seems to cause the lerk) and the others are at 1 - 2 % as usual
I spent hours to try to find solutions ... no success ... it seems that on my 4 systems I tried it on it switches from Hardware Acceleration to Software Rendering when in Windowed Mode ... I did not find a way to patch this - so ideas are welcome.


@RGR>>Which Blitz3d version do you use ?
Personally i use the 1.64 installation + 1.107 update

Which values do you give to the graphics3d function ?
Personally, i always write :
Graphics3d(pwidth,pheight,32,2)

and i have not seen any abnormal slowdown on several computers. (with windows xp, windows vista, windows 7, windows 8)
Soon i will be able to do some tests on a tablet with windows 8.1, i will report the results.


by curiosity, do you use sprites and the sprites functions ?


I may load up a cut version as demo this week if possible


This would be interesting.


RemiD(Posted 2015) [#15]
@Rick>>I want to add others improvements so i will post a demo later.
Basically i have modified some of the DSS functions and added others functions in order to decrease the time it takes to create the shadow volumes and to render the shadow volumes.

The cool thing is that maybe a similar lib could be created for Hardwired...