Have you found there to be any big hurdles developing a 3D engine in VisualBasic (I'm assuming that you're developing a 3D engine in VisualBasic :)

Looks like you are doing an excellent job.

Max

What sort of hardware are you using and what frame rates are you achieving at present?

I'm a hard core VB developer, but re-learning C/C++ to code for graphics.

The major hurdles that I have experienced was no documentation. I am lucky enough to know enough C++ to read it so I can try and convert people's code. There are some cases when I don't have the slightest clue on what their code does though. :)

The framerates I've been getting are a little disappointing. I've been getting around 20-15 fps at 1024x768 on a TNT2. I was expecting at least 30 fps, but it looks fine to me. I still need to do HSR which I have planned already.

Don't know what (if any) API you are using, but the VB library for DX has alot of documentation and samples. Look in the SDK starting with DX7.

If you know C++ why did you chose to develop the engine in VB? Are their any significant advantages?

Yes I know, but most of the documentation out there is in C++. I've seen VB tutorials and such, but there aren't too many out there. Anyway, I don't need them right now anyway.

I know how to read C++, but not write.

The only advantage that I can think of is that VB is really easy to use.

But there are still many disadvantages:
- VB has no pointers
- VB code is much slower than C code (thus you have to concentrate on hardware)
- VB (up to version 6) is not completely OO (will be compensated in VB7)

But there are still many disadvantages:
- VB has no pointers
yes it does, but it's undocumented. It might as well not have pointers though :)

- VB code is much slower than C code (thus you have to concentrate on hardware)
Not much slower

- VB (up to version 6) is not completely OO (will be compensated in VB7)
Yes it is.


Anyway, can we keep the VB war somewhere else?

All I gotta say, is with all these limitations why use VB? Yeah its easy to use, but so is Visual C++. Why do you program in it if you know C++?

My university Computer Graphics course for third years forces us to use VB to make a 3d engine - and I mean the whole thing - clipping, scan conversion, matrix transformations, the full nine yards.

I have seen many people go mad from the experience - try to implement span lists without decent pointers...

That said, I am abolutely in favour of using the right tool for the right job.

If it works for Mr Barnes, and allows him faster development, then where's the problem?

The shot's looking good. I look forward to a demo!

Well, VB code is significantly slower - maybe not on trivial applications, but if Unreal or Quake3 were made in VB, you'd be seeing around 5fps at best, methinks. ;)

If nothing else, VB might be faster to build a prototype in... remember, folks, that VB is really for GUI & Database programming, not game programming. If it had really been made for high-performace applications, it'd have a machine-code compiler instead of running on a p-code vm.

[Sarcasm]

Disadvantages of C++ over C:
Increased run-time overheadUneaven compiler support for various features (i.e. templates)Forces programmer to become intimately familiar with and "code for" a specific compiler or environment.Multiple ways to do the same thing (if you've ever worked on a huge project, you know how much confusion this causes)Further abstraction from the machine
[/Sarcasm]

Seriosly though, I just wanted to point out that
There is no "perfect" language,Every language has its purpose, andEvery programmer has their own reasons for using a particular language, some of which you might not have ever had to consider

Tim has already pointed out that he does not know the C++ language. Yes, he can read it, but that doesn't mean he can write an entire 3d language in it. If you hand me a Pascal source code listing, I can figure out what it does, but that doesn't mean I can write an enterprise-class web server.

Could we please at least try to keep the language wars out of here?

I meant "3d engine", not "3d language" (whatever that is).

It DOES have a native compiler. It's had one since VB5. It's quite fast also.

I answered this already

Ok, to answer a few questions let me start by saying that C++ isn't much more powerful than C++. VB has a native compiler which is pretty fast. Some of you may think that VB is slow because it is when you use GDI. It all depends on how you use it. The part that has the most stress is in the rendering portion of my program and DX does 90 percent of that anyway. Other calculations are handled by my app. There are things such as collision detection and network code that can slow down the app a bit, but not as much as you may think.

Earlier today I got the newest nVidia drivers and my framerate went from 15-20 fps at 1024x768 to 20-25 fps at the same resolution. I am also doing this without compiling the app so the engine should run at 30 fps compiled. Remember, I haven't added HSR or any form of sectored collision detection. Also, movinig the particles can be a major slowdown.

Anyway, do you have questions about my engine/game/screenshot?

">>Well, VB code is significantly slower - maybe not on trivial applications, but if Unreal or Quake3 were made in VB, you'd be seeing around 5fps at best, methinks. ;)"

I just want to add that not everyone is trying to make the next Quake 3 or Unreal. Believe it or not, a lot of people code simply because its fun/challenging. If Tim is realizing his own engine goals through VB, whether as a hobby or profession, that's great. I say keep up the good work.


">>Anyway, do you have questions about my engine/game/screenshot?"

Several IOTD comment threads lose focus of the image. I guess that's part of the fun. I posted a pic recently that happened to have a teapot in it, and it turned into a Utah Teapot discussion :) It was fun though. Anyway, to answer your question with some questions, do you have a link to a page for your engine/game? What are your goals for the engine anyway?

-> Several IOTD comment threads lose focus of the image. I guess that's part of the fun.

heh. I tend to do that sometimes.

-> Anyway, to answer your question with some questions
yay!

-> do you have a link to a page for your engine/game?
I do, but there's nothing on it. It's at http://www.gdarchive.net/capturedreality for now and will soon move to the server at http://gdtalker.cjb.net. I'll send another IOTD when it's done with a link to my page. :)

-> What are your goals for the engine anyway?
Some sort of networked FPS. Real simple, real small and just for fun.

Is there a way to do some sort of special quoting here?

Use can use html tags like

this could be someone else's quote

You can use the 'I' tag .. italic tag or something

Very nice. Do you plan on implementing lightmaps? Also, what sort of data structure are you using for your particles? Do you store them in a collection or an array or what?

I would like to say also, I know youre sick of hearing it, but I would like to give my two cents on VB.
Visual Basic got a lot of bad press in its earlier years because it ran under a VM, and was very slow. Most people therefore shunned it and refused to learn it. That's ignorant in my opinion. Visual Basic has many many advantages over C/C++ too many for me to go into here.

A couple of facts for you people, unreal did utilize Visual Basic for their editor. Unfortunately, the folks didnt know how to use VB very well, and they since rewrote it in C++. Thats not a language fault, its theirs. Also, in just a few short lines of code, I can make a very robust network application in Visual Basic.

Point in case, if you dont know what you are saying, dont say it.

Once again, very nice screenshot, Im particuliarly inmpressed with the particle engine, and the translucent HUD. Any comments about the implementation of these would be appreciated.

As far as I know, this board accepts any kind of html.

I often use italics ( tag ) when quoting other messages.

I've seen others use bold-face ( tag ), when responding to questions, for example.

->Very nice. Do you plan on implementing lightmaps?
Yes. I did once, but the edges of the poly's were very obvious.

->Also, what sort of data structure are you using for your particles? Do you store them in a collection or an array or what?
I use an array. Here's the type

Public Type Particle
Direction as D3DVECTOR
Position as D3DVECTOR
ColorSrc as D3DCOLORVALUE
ColorDest as D3DCOLORVALUE
Life as Single
FadeSpeed as Single
End Type

and I think that's the whole struct. I don't have the code on this computer :)

->I would like to say also, I know youre sick of hearing it, but I would like to give my two cents on VB.
ya. But it looks nice for a change :)

->Visual Basic got a lot of bad press in its earlier years because it ran under a VM, and was very slow. Most people therefore shunned it and refused to learn it. That's ignorant in my opinion. Visual Basic has many many advantages over C/C++ too many for me to go into here.

A couple of facts for you people, unreal did utilize Visual Basic for their editor. Unfortunately, the folks didnt know how to use VB very well, and they since rewrote it in C++. Thats not a language fault, its theirs. Also, in just a few short lines of code, I can make a very robust network application in Visual Basic.

Point in case, if you dont know what you are saying, dont say it.
I totally agree. I might quote you in my game somewhere if you don't mind :)

->Once again, very nice screenshot, Im particuliarly inmpressed with the particle engine, and the translucent HUD. Any comments about the implementation of these would be appreciated.
thanks. I made the particle engine using nehe's particle engine from http://nehe.gamedev.net. The translucent HUD (soon to be redone) is a Transformed and lit array of verts. Anything that is 2D is really 3D in the whole game.

Very nice!. can't wait for some more screen shots.

About Timothy's goals of the engine. Didn't you say on gamedev that you want to make a game to rival the graphics in quake3.

Grr.... I strongly dislike Mark Friedenbach for dissing up C++, honestly he doesn't know a thing.

#1 - C++ makes code nicer looking
#2 - C++ has been known to IMPROVE application speeds (templates for example)
#3 - You do NOT have to be intimately familiar with your environment. There is something called ANSI C++, the additional features provided by the compiler are independant of that.
Even funnier is the fact that there is only ONE VB ENVIRONMENT, there is no such thing as Borland VB, so who is becoming more intimate with their environment?!?!
#4 - There is not further abstraction from the machine, C++ code compiles into assembly just like C and still supports inline assembly.
#5 - Many ways to do things? are you doped up? Of course there are many ways to do the same thing, C++ actually makes this easier with its encapsulation features. "Single Interface, Multiple Methods", something like that. C++ can create single black boxes that other programmers need not be concerned about. So take your thoughts on C++ and bury them

I am a hybrid C and C++ programmer and I find no disadvantage to either language. I also use VB for things I want to do fast.

- Tom

Good lord. Liquid Darkness said that. I swear it, I'm not going for that. We straightened it out and agreed that GLQuake was our goal :)

First off, he didn't diss C++. And secondly, there is another VB interface which is cross platform. That's realbasic. I think it's www.realbasic.com

Well, before the image gets changed, I'd just like to say that this has been the best "VB vs. C++" like discussion I've ever had. A lot more of you liked my work than I expected also. :)

Nice picture. I'm assuming a basic particle system (no pun intended there) with one-one src-dst blending, (or something along those lines, doesn't look like it uses an alpha channel). I was mostly just wondering what you're using for the data. You said about implementing HSR and BSP, are you using ID type BSP levels or just some raw format you put together from scratch? Anyways, kool level, can't wait for a demo, look very Escher-eske with the tiled floor and walkways.