Beyond Virtual

[patrickrho]

I used BV thoroughly...and came back to TV...used BV..came back to TV..used BV and came back to TV

BV has lots of features...the engine seems like it is mainly for artists, as the art pipeline is very very linear and logical..u just gotta drop the model into the editor, and dat's it

but i think that's the only feature that is above TV.  Not to mention the ease of use of BV, but it's all because of the editor. You just drop the item, place an item, and boom, you just created a stage.  No BSPs, dats one thing I like about.  Also very good GUI system, very flexible. But what made me go back to TV is the flexibility and stability.  BV's scripting is VERY limited.  they included "INCLUDE" feature so you could include other scripts but it is not meant for everything, you can't include dynamics and other movements.

Also, there are a lot of bugs in BV.  The fact that the devs of BV denies it is kind of funny, actually saying one of the shadow bug is due to users' graphics card overheating...well...and to fix that shadow problem, you have to downgrade your nvidia driver to lower version, which means you have to tell each every one of the users that are playing your game to lower their drivers to the lower version...hmmm...

The physics is buggy too..if you put 50 boxes together stacked, they do some weird stuff together, like they jiggle and twist, but of course the boxes stay together, but it looks like the wind is blowing and they're like trying to stay together..This can be fixed if you change the physics dynamics per second settings, but changing that to a higher value DRAMATICALLY reduces your FPS...i have a high end machine and I still get like 20 to 30 FPS, no higher for 50 boxes..

TV 6.5 will beat it when PlanetX editor comes out, since it could do terrain morphing and object dropping right there in the editor.  Editor and GUI is what TV needs, and TVGUI and PlanetX editor are on the way, and if they are stable enough to be a "MUST" for TV6.5 then i think TV will surely be number 1 in DevMaster.net engine list.

just my $0.02

[stodge]

BV's car demo is not bad but at times you can see the rendering speed peaking. The physics demo with the falling boxes runs at about 2fps on my AMD64 3200 with 1Gb + GeForce 6600GT.

[satch]

well i use both.. its a lot of fun how fast you can work with BV..

- wysiwyg editor
- easy art integration (pity that Truevision doesn't support FBX!) BV does..
- road system is nice, just draw your lines and then select a mesh to fill
- easy entity placement
- no compilation


some bad things, to be honest:
- needs to mature (its a very young engine)
- no shaders yet
- takes 2-3 days until somebody will answer a question (gdgc is a small company)
- you are forced to show a splash
- still some bugs in and a bit slow sometimes..

but download the starter, its really great!


TV3D needs a official wysiwyg editor and it will be kick ass!
(graphically BV can learn much from TV3d)

[Albertus]

Satch

I have read that  fps drops to 5 - 6 with 50.000 tris
Is it true ?

[darqSHADOW]

- wysiwyg editor

While this is a "nice" feature, it also hinders the end user, since there is no way one editor can be used for every project TV3D is used for.

- easy art integration (pity that Truevision doesn't support FBX!) BV does..

FBX is a proprietary format, and is not DX native.  Therefore it would need to be converted internally in the engine, causing a slowdown.  It also would mean more code paths for incoming and outgoing meshes, causing even more bloated code, not a good thing.  We use the DX format (X) as our internal format, TVM and TVA are nothing more than X models with extra TV3D specific mesh information included.

- no compilation

This is NOT a good thing, this means that during runtime you are interpreting the script.  This will inheritantly make the engine slower than even VB code, which at least compiles to a native form.

- no shaders yet

This is a requirement in todays market.

- takes 2-3 days until somebody will answer a question (gdgc is a small company)

Truevision3D is also a small company, yet we manage to stay in constant contact with our customer and user base.  Considering there are only 2 of us at this time answering questions and coding there are not many companies out that can say they are smaller than us.

DS

[RuntimeError101]

Just tried this thing.  FPS is terrible.  I made a simple scene and the FPS just dropped.

[Lyrical]

Havn't spent much time looking into this but i prefer TV3D mainly for the
.Net support and i don't like scripting i prefer hard coding c# c++ etc.

Maybe i'm wrong but why use a scripting language when we are all programmers
here why learn another language.

just my imediate thoughts anyway.

Enjoy TV3D, I DO

   

[Oxygen]

i prefer TV3D mainly for the
.Net support and i don't like scripting i prefer hard coding c# c++ etc.

Look in to Reflection. You can create c# classes that compile at runtime. It's like hard coding, but the code isn't compiled until the program runs. That way you can have a fully scriptable interface with the same exact workflow as hardcoding without the code in the executable or library.

[Raine]

Even though I'm a hardcore Reflection fan - which is one of the most exciting things in .net - I wouldn't recommend it in a 3d context. It's slow.
Another solution could be writing a simple parser and feeding opcodes to a dynamic method - along with the proper objects.
You can precache these methods on load and invoke them while the app is running.

[sybixsus]

<oops>

[Albertus]

.

 why use a scripting language when we are all programmers

 

A  script language is not only more intuitive  than pure c++ but  you dont need to recomplile wheneve you you want to test your code
Time saving is an importat issue  for example for  game logic

[AriusMyst]

Execution speed is important too. Especially in game dev. I suppose its a balance, but I know which side of the fence I sit on.

[TMichael]

I like being able to script. It can save considerable development time, but like Arius said, there is definitely a balance. Just avoid scripting for time intensive tasks which could create a bottleneck.

Cheers,
Tim

[AriusMyst]

Yea, scripting has its place.  

[BlindSide]

Most games these days implement both. Core engine logic is always, always written in a language that gets compiled down - every single millisecond of execution speed makes a difference. However, it's extremely common for NPC AI, in-game cinematics, even UI's to be fully scripted. As games are required to be a fair bit more complex than the days of Doom, it is only natural that scripting has found its place. It makes very little sense to have to rebuild every time you want to change the way an NPC character approachs the protagonist in the town tavern.

However, it's dangerous to make core game logic through scripting. It is easier, and you can get away with it for rapid prototyping, but the rule of thumb is: If it doesn't need to be fast, then script it. Well, the fact is, logic that is processed every single frame needs to be fast - that can't be argued.

[Albertus]

A typical game logic  loop is  : set  your parameters  - watch - set ...- watch -  ..set..

It would be really useless to recompile anytime

Once you are happy you can write your final version in C++ if speed is  a main issue
Is it a really a  issue ?
as far as the core of engine is concerned definitly yes , but for the game play ...there are so many other bottlenecks in a game

[AriusMyst]

There are other bottle necks, this is true. That shouldn't mean you should ignore the most easy to fix bottle necks. I'm not saying for a second that anybody not programming in C++ is a fool and will suffer from speed issues. I'm just saying scripting has its place - an that place is not within main game engine design( which EVERYBODY using TV should be looking at - as its not a game engine on its own ). Scripting is very important, but knowing when to use it and when to use pure code is FAR more important.