Looks very interesting.

I would say doing it the way aroung (First OpenGL, then Direct3D, then SW only) is easier. You should loose lots of speeds when just using the Win32 API. OpenGL with some special extensions or even better DirectDraw is much better for getting your stuff finally on the screen. GameDev.net has some cool tutorial about DirectDraw and I have a framewok on my site (glvelocity.gamedev.net).

I don't think that the DDraw renderer makes your code less portable than using DIBs / WinG.

Keep up the good work.

Tim

Nice work!

I've taken a look at your code and I must say it's very clear and good OOP in my opinion.

I'm also working on a full software engine, but I'm using DirectDraw to get fullscreen resolutions and a pointer 'directly' to video memory. I'm not sure but I think it's a lot faster than using the Win32 API, since it's 'directly' connected to the windows operating system.

I see you're planning to do texture mapping, maybe these articles will help: Perspective Texture Mapping.

Greetings,

Nick

If you need fast 2d rendering and don't want to mess around with DD you might want to take a look at OpenPTC or TinyPTC. These are very fast and easy to use libraries (I think you can even use OpenPTC with Java! Right?).

If you want to go the hard (Microsoft-) way there's this very good tutorial at Gamedev called Game Programming Genesis. If you're already familiar with WinAPI-programming you can skip the first 3 parts and go directly to part 4. This is a very, very good tutorial on DD (but quite lengthy...).

Ciao,
Moonbird

I like PTC, but i have moved over to DD because i think it's much more friendlier for the programmer. Both are very good thou, try both and you will learn a lot...

/maq

Thanks for the encouragement guys.

tcs -- I think when porting to Java the DIBs are more portable because the're a lot more similar to Java's AWT classes then DirectDraw is. I've been to your site befire and I love your demos. I'll take a look at that framework.

Nick -- Thanks. I'll read that.

Moonbird -- I don't really like using other people's libraries in my personal projects. I appreciate the speed of development they afford at work, but at home it kinds feels like it detracts from the challenge. I actually have the tutorials from GameDev saved to my hard drive, and the tutorials on the windows API were really helpful while I was learning to do this.

I wonder if it's feasible to support both DIBs through the API and DirectDraw? I know DirectDraw is faster, but I want to use this engine to write "desktop games". You know, the ones you play for five minutes while your waiting for a website to load? So I want it to be able to run on the oldest hardware plausible.

Well, unless you're coding for Win16 (Windows 3.1), DirectX will run on whatever hardware there is. You can even use DirectX 3 if you want to support older versions of NT.

Its not like there are any OSs other than Windows that he might refer to by "portable". This is java after all.

*cough*

That is why something like TinyPtc (which is an API in its own right is good). But, if he wants to avoid 3rd party libraries, some sort of DIB system is a good way to do that - because it is easier to port.

Quite right DirtyPunk. If I wanted to write a 3D Java Applet that would work on other OSs such as Mac OS and Linux, I wouldn't be able to rely on DirectX. This is more a learning project then anything else, so I'm not to worried about having the best possible engine.

The next thing I need to impliment is some sort of depth culling so the back doesn't appear in front of the front. :-) My goal is to obtain a speed of 15/20fps running about 10,000 polys. Basically I want it to run smooth when I put the terrain on maximum detail. I'm not sure it's possible, but I'm going to try.

If you want portability (hint: you want portability), use SDL (available from Loki Entertainment - check their development section, IIRC). It's a very thin wrapper around a number of graphics and sound APIs, such as DirectX, DGA/GGI/Xshm (various Linux/UNIX equivalents of DirectDraw), and I believe Mac as well (but don't quite me on that). It also makes it easy to grab an OpenGL surface, so that when you do take the plunge of writing a hardware renderer (and IMO, the other posters are wrong - learning software first is DEFINITELY better, since then you get a much better grasp of what's going on in the hardware), you can still keep things nice and portable. :)

My goal is to obtain a speed of 15/20fps running about 10,000 polys.

Depending on the level of compatibility you're targeting (for instance, if you wanted your program to run as an applet and work in as many browsers as possible, and/or on as many operating systems, etc.) you may need to restrict your use of Java class libraries to those which are Java 1.0 compatible... Like the Java 1.0 event model, etc. The reason I bring this up with regard to framerate, is because the standard way of getting custom-rendered pixels onto the screen in Java is, in my experience so far, very very slow.

If you were rendering into a 640x480 buffer for example, the best you can hope for, from what I've seen, is in the 15/20fps range just for copying the pixels to the screen! And that was using the technique TinyPTC uses in Java of making itself the ImageProducer (which is about as "low level" as you can get in AWT to my knowledge, at least for Java 1.0 compatibility.)

[Note, my machine is not the fastest thing around these days, a mere 300MHz PII... so Your Framerate May Vary :)]

So the point here was really intended to get at two things, I guess. One, that there may be a faster way to get pixels on the screen in some of the newer Java APIs, like Java 2D - I haven't investigated it yet because in my case I needed Java 1.0 compatibility anyway...

But also, that if you ARE using standard AWT stuff to get your pixels on the screen, and you're looking for a peppy framerate, well, to borrow a line from the Princess Bride, "...get used to disappointment." ;-)

I have a little test applet at:
http://www.foosenblat.org/ftp/java/testpix/test.html
It is just the TinyPTC example code, with some stuff added to measure the framerate, and blitting into a larger window (512x450).
(The code is in the testpix/ directory.)

So, the ugly part is, the code that renders the "static" into the buffer, can actually do its job at about 120fps on my machine. But just copying those pixels into the window drops the framerate to 15fps. !!!

Okay... just wanted to warn you where the major framerate bottleneck seems to be in Java - but if you or anyone has experience to the contrary I'd certainly love to hear it!

Anyway, best of luck with your project,

Bill

"[...] and I believe Mac as well (but don't quite me on that)"

Yep, SDL has versions for Mac and BeOS (although I think the Mac version is in an alpha stage).

Max

I see that you mean. My machines's an AMD K6-2 350Mhz, and your applet gave me just above 15 fps (12 on netscape). It seemed to me that my applets ran faster then that, but then again I don't think I've ever done one that size. I seriously doubt I'd achive my speed goal with a java applet, since java is interpreted and can be around 20 times slower then native code. I figure I'd use my engine for an actual game, with multiple characters, landscapes, sfx, etc. And then write a java applet simply as a single mesh viewer. So the applet wouldn't need to handle nearly as many polygons. It couldn't, really. Although I saw an IOTD posted recently with a rather impressive 3D Java applet. It seemed to run pretty fast, faster then would seem to be possible. So I don't know.

the only problem with those multi-platform libs (other than the bugs) is how they often force you into some hideously ugly coding style...

or maybe i'm just ahvign a nightmare... at 10:07pm when i should be coding :P

-- Codeman

Java3D makes direct use of OpenGl (or Direct3d) hardware acceleration. This of couse is faster than using Java1.0 techniques. I would use Java1.2 with Java2d. This makes use of DirectDraw on a Windows machine and I guess of something else on another os. It's quite fast actually. If you want to run this as an applet you need Java Plugin installed.

hdmx

Codeman: And DirectX doesn't? Frankly, SDL and OpenGL are incredibly clean and flexible by comparison...