Sorry your browser is not supported!

OK then am playing around with a driving type game. I'm planning on having very large desert like areas sprinkled with occasional buildings. I would rather like to be able to get out of a vehicle and walk into a building. Now clearly BSPs are a good way of doing the inside areas but will the outside areas cope well as bsp? And will I be able to get the equivelent of a groundheight command to allow the vehicel to follow the contours of the area properly?

So is the best option to

A: code the outdoors and indoors seperately as terrain or matrix and bsp - allows best outdoors and indoors code but would almost be 2 seperate programs.
B: code the maps as matrixs, the buildings as stationary objects and figure out the sliding collision to allow you to do a FSP style wander round them - would allow you to move between the indoors outside areas better but would limit the complexity of the buildings.
C: do the whole thing as a series of bsps?


Final question terrain or matrix? Which is generally better for landscapes

For a racing game i wouldn't recommend using BSP at all, it's just way too slow in DBPRO. Plus there are licence issues with BSP creators like worldcraft unless u use a .x to bsp converter.i would think u should go with option B.

I had a nasty feeling you were going to say that

Think I'll do the driving bit first and see how I can adapt it for out of car stuff!

you could in theory, if entering the buildings is that important, use a simple static model but once you cross a certain point in the door switch to a BSP!

Only problem with this is you'll have loading times for the bsp, but if you fade the screen out when you open the door it mightn't seem so bad!

"For a racing game i wouldn't recommend using BSP at all, it's just way too slow in DBPRO."

WHAT !?! - BSP is very fast in DBPro - I get 190FPS on a good sized BSP! (and I don't have a hugely ninja system either) Loading times aren't too bad either, but you mustn't have a massively complicated huge BSP.

However I recommend matrix + terrain + x models because BSPs are really only for indoor environments. Matrixes are much faster if you can use them (in terms of loading speed, not actual operation speed)

I agree - BSPs are pretty much an indoor FPS only thang - otherwise they are way too limited. I agree however that they are v fast

BSP are generally only fast on thier own in compressed areas...

Remember games arn't simply Controls + BSP world
And you might want the game to run on a system lower than a 1.5Ghz P4 w/GeForce4 Ti

When you add in even a relatively decent Physics engine you can expect to loose ALOT of speed!

Not to mention BSP is designed to show only around 1,000 to 5,000 polygons per scene.
Whereas no doubt you'll want alot of buildings, vehicles, etc...

Lastly BSP is not a SMALL format by any means, nor is it particularly friendly to load... so say you have 4 or 5 types of building you wish to go into - at around 10,000 polygon courses (using Q3 BSP because of the Patch Spline Mesh) then really you're looking at around 10Mb per BSP level.
x4 and that 40MB!!

and i'm not meaning thats 40MB for downloading because most won't care ... i mean thats atleast 40MB of Ram the end user will need as well as the Ram required for the games needs.
Might not seem like much to you, but remember that windows requires atlest 16Mb free at anyone time (4Mb for 9x) as well as the fact that it doesn't enjoy having less than 32Mb free generally.

So you're looking at wanting the user to have around 96-128Mb as standard.
if you add this with the need of the models (remember models maybe loaded once by pre-rendering they take up the same again within the main system ram as a buffer)

in the end really the benifits don't really outweight the costs.
Now if you developed a format which INCLUDED Bsp as part of it ... then that would be a different story

The physics system isnt hugely complicated, enough to handle chages in velocity and angle after collisions an so forth but as its all using spheres for the maths its pretty quick (but not 100% accurate )

Played around with terrains last night and found some very strange results coming out of the get terrain height command, so switched it over to matrixes and that seems to work nicely so will probably stick with them.

I'm not planning on having large numbers of buildings, I'm going for the desert/wasteland feel. So maybe a few 5-9 house clusters at the most but if I limit the amount you can enter it should keep the frame rate up. After all at its very simplest a house is just a box. I reckon if the textures are good I can probably get it to work. Most of the time you'll be looking at just one or two buildings and a tree or two.

@Raven

I think you are being way to negative about BSPs. Your reasons make sense but from the tests that I have done, even with loads of objects on screen, wide open spaces and complex geometry, BSPs are very fast.

but ALMOST every user here has a pretty powerful system...
remeber Professional Minimum Spec is a
Pentium2 266
32Mb Ram
8Mb Direct3D Card

DarkBasic is slower than Quake3 at Rendering its equivilant BSP ... because the engine can't be specifically developed to render the pipeline around the BSP - and if it did then would make making other games harder.

its very easi to get 100+ fps on large object counts with complex BSP geometry even with wide open places in Pro on a P4 1Ghz+ - 256Mb+ DDR/RDRam - GeForce4 Ti
i mean geez, i could always just plug in my GeForce FX and even this dinky 800Mhz system would run it without blinking an eye at 2048x960 with say 500 objects onscreen.

Try plugging an older card into your machine and then try the same test ... my VirgeDx was never designed to accelerate on the scale that Professional asks of it in complex worlds. Then it has to rely on the processor more which most of the test that i and other have done show that Pro isn't optimised for Processors, meaning it runs as if it is a Standard x86 32bit processor.

i don' think that BSP is a bad format... it is just bad for what people are trying to ask of it.
Once you have a fully laden game you'll understand, something you can't achieve in a pure stress test ... because you don't have the many factions at work that are in a main game program!

I get a very respectable 25FPS on my RivaTNT 1, 350Mhz, 64MB RAM machine - which I would consider to be the absolute baseline. Quake 3 gets about 30-40 FPS on this. This is at 640x480.

kinda my point here ... i mean 25fps is "respectable" if your using a timer based routine.

most people don't - plus as i said its just a stress test rather than a full engine test.
i'll see what i can do over the next few days in my freetime to make a basic enough full game akin to Q3.

then we can test it properly... i mean personally i still use a P2 300Mhz | Savage4 Pro | 420Mb machine as the baseline system, Althon 500Mhz | GeForce2mx 400 | 256Mb machine as the adverage and AlthonXP 1.2Ghz | GeForce4 Ti 4600 | 512Mb as the max

so anything over that on the things i develop is just overkill for high resolutions.
Which personally i prefer 800x600 with 2x FSAA over 2024x960 - but then thats just me

I load in CS levels and in teh most open area i can find i clock up over 750 FPS, and i dont have a knock out system, im on a 933 for god sake.
i get over 800 FPS on a dbdn quake level and that map is intense

bsp is fine for outdoors, IF you knwo how to use it, no f00l can jsut dive in and expect great results

RV: 10,000 polys a building??...please dont make me slapp you, i think he means 1-2 story buildings, not intricate sky scrapers....O_o

10mb a level, are you insane?, counter-strike levels dont even touch that...


For me BSP is very fast and easy to use, i dont think im an expert but i dotn find anyhting hard about them.... noting..... absolutely nothing, if you ahve trouble read up about them, learn and dont complain.

Not to mention BSP is designed to show only around 1,000 to 5,000 polygons per scene

R U CRAZY, what the hell levels are you talking about
BSP are designed to be in enclosed areas, ala a sewer, how the F*** can a sewer produce 1,000 polys on screen, for one id say the map designer is the worst mapper ever and he should be shot, and two....ofcourse that would be slow, its stupid, that would be on an average sixed level that map would end out having about.....120-300 thousand polygons and that ludicrous.

RV i dotn know what planet your gettign your maps from mate, but you need to start thinking realistically about them and what ppls needs are on DBPro games.

IE.

say you have 4 or 5 types of building you wish to go into - at around 10,000 polygon courses (using Q3 BSP because of the Patch Spline Mesh) then really you're looking at around 10Mb per BSP level.
x4 and that 40MB!!

i mean c'mon, seriously

To clear a few things up- by open areas I'm talking about large relatively flat or slightly undulating, terrain. Not a rather large courtyard.

And buildings will be one, or at most two stories, mostly with only 1 or 2 rooms per floor.

I always use timer-based routines, and I don't understand why anybody would not. It isn't exactly hard either - when manipulating an ojbect you just have to do distance/FPS >> easy The alternative is to lock the game at a speed, eg 30FPS, but I don't like doing that. I take your point though - timer based routines do take some effort and too few people use them.

Also dont forget the terrain commands, are they working though? hehe

I will be using timer based. but I'm doing position=old position +speed/fps and speed = old speed + acceleration/fps

Pathfinder - I did have some problems using terrain - in particular the command to return the ground height gave unreliable results, although it worked OK in the example codes. Probably just my syntax again.

Anyway I switched to a good old fashioned matrix and everything worked fine so unless theres some pressing reason to I'll stick with that

Insider are you aware to how BSP is used? How the visibility is calculated?

< | --> |

^Camera ^Vis Beam

There is a beam almost literally shot from the current centre eyepoint of the user camera ... it moves along calculating its tragectory everstep until it hits a polygon, and the collision is then based down the Vis Tree (the arrayed visibilty data) based upon the current vector.

it must do this for almost every possible angle, and the further the distance the heavier the calculations + heavier the presicion becomes because it is checking more and more at a greater distance.
And the Vis works like a monitor only does a single beam at a time so it takes time to sync the whole screen then check that against the Tree and finally do a ZBuffer on it all.

It is apparent that BSP within Pro is slower doing a stress test over Quake3 which is a fully laden (and not optimised to allow for Modifications) engine!

Have you ever played quake3 Rally? My Althon 800 w/GeForce2 Ti Ultra and 256Mb Ram can scrape up around 35fps at 640x480!
The main reason is because the Car Physics which has to be calculated ... Add this with the BSP checks, and really its useless.

Also 10,000 for an indoor arena is quite a sound judgement, because remember the track has to be relatively smooth else it causes the physics to have to be recoded (same goes for the outdoor areas), plus the crowds, you're not sure what the indoor areas will contain - if its a city then its likely there will be shops and people!

Plus the mall like things, or even the stalls within the shops themselves!

Mapping products arn't like modelling products, and if you do use a model instead of a prefabrication - then it isn't Visibilitied THAT will be full polygons.

Plus 10Mb for a Counter-Strike world is about adverage, i mean you're going to have Textures arn't you?
Alot of CS levels use what comes with the product - you ever seen one with all the textures in a seperate pak?
THEY all have to be loaded into memory too, so don't forget the slowdown from that.

I mean BSP is fine as long as your system can handle it - but we've already established time and time again that Professional relys almost entirely upon your graphics card.

Next time you run your BSP world, use the statistic(1) command if you want to know how many polygons your get... no you won't get 1,000 all the time but these are the peak expectancies and we are talking about people who DON'T have years of experience developing maps, understanding optimisations, and want to make thier games rival titles suchas Burnout2 - so the cars are probably not exactly likely to be low polygon either!

Insider try to remember i'm not talking from a newbies point of veiw here, i've developed worlds in this format for over 7years, i've a good working knowlage of how scenes should be setup, i also have coded in this format and seen TTOOO many OpenGL engines using this format in a debug state and what it is capable of.

Insider also remember that CS has pretty small worlds, which if you drove a car in them you'd hit the end of the world before you hit 20mph.

Infact they're Smaller than Half-Lifes Single Player portalised worlds - with ALOT less detail too.
If he is thinking something in the Range of GTA3:Vice City worlds, then BSP will be good in the buildings - however it will ALL need to be preloaded, because loading times of BSP is just intolerable.

But then again swapping between formats for indoors and outdoors is stupid because you also have to change the collision setup - which can be more costly than good.

BSP is a one trick poney - which on its own is fine, once you get it out of its area of expertise and such it dies horribly. Personally i hope that with DarkBasic World format they'll take a very different approach to the visibility setup - i think the N64's ZBuffer Cull is probably one of the safest bets, that way the format doesn't need it at all it can be built into the engine. Anything the ZBuffer detects as hidden and the rest of the geometry within that area is hidden.

And if you don't believe that BSP is now getting too old play ANY of the newer games on lower end systems that use BSP - perhaps you can be happy with 14-25fps personally though i'm a firm believer that anything under 30fps is a waste of time.

When you have FPS that low it affect EVERYTHING not just the games referesh speed.