Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 


Submitted by Mike Boeh, posted on August 16, 2000




Image Description, by Mike Boeh



This is the retro game, Bugatron, that I am working on. It takes influences from games like DX-Ball, Galaga, Bill's Tomato Game, Centipede, etc....I am actually pretty far along with it. It uses renderit3d from indotek, which is basically a d3d IM wrapper (although I have to go into dx/d3d a lot anyway) and it's pretty good. The one feature it lacks that just KILLS me is that you can't send it's loading functions file pointers- so I cant use my .wad file coding. Anyway, my engine features: nothing! It is pretty vanilla d3d here. I am envious and amazed by some of these fantastic IOTD's but I am focusing on true retro playability and you wont be blown away by anything here. But I hope it is a fun game that's a throwback and is really a 2d game in 3d space. One interesting thing about it is that there is so little fill going on, that it runs great on my machine even at 1600x1200. You have to be online to play it, as the 6 xml levels are only on my www site (even the splash screen is an xml level). The XML parser code is from my good friend, Mike Welch, of DX-Ball fame. Also, I have not tested it on any cards except for my diamond viper2 under win98, so I would GREATLY appreciate if you could mail me what your system specs are, and if it ran, and what it's logic and render time was (hit f11 to get that info). My email is mike@retro64.com. The "test" can be downloaded from http://www.retro64.com/bugtest.zip

-mike!


[prev]
Image of the Day Gallery
www.flipcode.com

[next]

 
Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Mike Boeh

August 16, 2000, 01:30 AM

I showed it to some people on irc today- I think it has some nvidia issues ie: choppy fps....

 
Nibbler!

August 16, 2000, 01:45 AM

The game is cool!
Lots of fun.
It worked fine on my Tnt2 ultra.

 
Axeman

August 16, 2000, 01:55 AM

Good job dude.. I told ya it'd make it! ; )
Looks great!!

 
Willem

August 16, 2000, 03:00 AM

Very nice! I was instantly hooked. I like retro-stuff. It's the way games should be made: with 100% gameplay in mind. That's what many game developers today forget, it's not Graphics that's got the highest priority, it's gameplay.

 
Greg Horne

August 16, 2000, 03:19 AM

Damn! It bombed out on my Voodoo2 SLI setup. Hope that helps a bit.....

 
Paul

August 16, 2000, 09:43 AM

It ran perfectly on my PIII-500mhz, with 128 megs of RAM, and TNT2 Ultra at 1024x768 with 32bpp color. I had fun playing your game. Nice job. It looks fantastic.

I have one question that I hope you won't mind answering. Are you rendering everything in the same view-space, or is each object rendered in its own view-space and then copied to the backbuffer?

Whatever you're doing, it looks really good.

 
Mike Boeh

August 16, 2000, 10:12 AM

They are all rendered together in a world space. All the stuff converges to a z value of 0 very quickly. I have code in there to do an isometric view, but it makes it alot harder to hit those little buggers :D Thanks for the info. I had some timing issues with the version I sent out. If anyone has the time, I would love to compare the numbers of this version with the ones in an update exe i put on my site: http://www.retro64.com/bugnovs.zip

thanks the feedback so far!

-mike

 
fluffy

August 16, 2000, 11:46 AM

Looks really cool. Not to sound disparraging, though, but why not do all your own rendering code if you've ended up needing to write most of the stuff yourself and the third-party stuff you're using makes things more difficult for you? I mean, what could this library be doing which makes its functionality worth the complete loss of flexibility you've gotten? After all, writing your own object loader and renderer isn't that hard...

That said, it's too bad you're using D3D and not OpenGL. I'd love to see this under Linux. Oh well. :)

 
Mike Boeh

August 16, 2000, 12:05 PM

In retrospect, i would have just used OpenGL, you are right. But renderit is a very nice clean api for a novice. Still, I thought it would save me development time, and I'm sure it probably has. I wanted a quick development cycle, and RenderIt has given me that- and at least they allow me to get at the "nuts and bolts" of dx7 too. Hey, you gotta start somewhere :-)

 
Capt. Neville

August 16, 2000, 01:06 PM

@*#&*(*&@# NEATO!!!! The screen goes all screwy at launch, then runs fine from there and looks NEAT! (bit small in windowed mode to see it, but oh well :)

Keep up the great work!

(700mhz PIII, GeForce2, in case you're wondering)

--Capt. Neville

 
Isaack Rasmussen

August 16, 2000, 04:48 PM

Hi,

Really nice game... but! Why does it require netaccess? I'm on a dialup, and denying your game online access, makes it crash.

What is it you are sending??? And can't you make a version that does not require onlineaccess, so that I can play it without connecting to the Internet every time.

Also, I'm not having much luck getting it to run in 32bit 1152x864, the game doesn't show textures.

Geforce2 MX, Detonator3 Win2k

Isaack

 
Mats Linden

August 16, 2000, 04:55 PM

This game will be highly addictive... The flasing in the beginig sort of reminded me of the loading of old C64 tape games.... btw It runs great at all resolutions up to 1280x1024x32 on a PIII 500 with a voodoo5 5500...

 
Mike Boeh

August 16, 2000, 05:27 PM

It is just loading the levels from my web site. They are < 3k each. I did it that way so I can change them at any time. Also, the high score will be handled by the web site (asp code) so that it is global. I am also toying with the idea of advertising as a means of revenue- which would require the user being online. I will fix the crash if not online and the alt-tabbing issues.
Isaak, how much memory does your geforce MX have? 32 meg? If so, it SHOULD work, but like I said, I have only tested it on my 32 mb viper2.
The flashing at the beginning is intentional and totally useless, i just wanted it to look like a c64 :P

 
DragonWorx

August 16, 2000, 07:34 PM

Finally!

An IOTD which is about the retro feel. I use macs, so i couldn't run your game. But it looks funky anyway.

I grew up on games like DoubleDragon, Shinobi, Rambo, Raiden etc...There are game players out there who think that 2D can only be frogger or pac-man. Every game in the arcades now last's for one minute, needs a manual to learn, and has crap game play.

If you want to stand out, you must be original. Let the 3D first person shootem ups do their thing, personally i think it's so repeditive, and a bit *sick* actually. The Quake engine costs $500,000 - for what? so you can make another Quake? Let Cormack do those games, i'd rather play something else.

Be warned, the 2D RETRO revlolution is at hand!
Viva la Revolution!

"Blessed are the cheese makers..." - Life of Brian

 
Alex Taylor

August 16, 2000, 07:41 PM

That was cool. I ran it on a PIII 500 w/ 32Mb GeForce 256 DDR under win2k. It was groovy. I didn't try out all the resolutions, but I was playing it at 1600x1200 with no problem. Good work.

 
bactierra

August 16, 2000, 07:56 PM

Uh, Mac Guy: this is a 3D game, it just plays like a 2d game... But I see specular lighting all over and the enemie bugs come from the distance. The feel is of a 2d game though and it is fun as hell to play. I just wish there were more levels (that eyes one is hard). V3, p2 450, ran smooth as a ken doll's crotch.

 
fluffy

August 16, 2000, 09:50 PM

bactierra: 3D rendered graphics != 3D game. If the gameplay exists only in 2 dimensions, then it's a 2D game. Kinda like how Doom is generally considered a 2.5D game since its "height" really only amounts to a display hack and one-way barriers (I mean, really, it's about as 3D as the SNES and Gameboy Zelda games are. ;)

Mike: Since you would like to have done it in OpenGL from the outset, any chance you'd consider recoding it from scratch when you're no longer a newbie? :) Switching to OpenGL from Direct3D is probably really simple, since OpenGL is a very simple, consistent, easy-to-learn API (unlike Direct3D). (Anyone who wants to flame me for that: I've been writing software 3D renderers since I was 13 - I'm 22 now. I used to code my inner loops in x86 assembler. I've written robotics control programs - in assembler - for the Motorola 68HC11. I think I'm somewhat qualified to say what's difficult and what isn't. Direct3D is difficult. OpenGL isn't. :)

Er, ennyhoo. Yeah. Really, writing your own basic scene setup/display stuff in OpenGL is really easy - between compiled displaylists and the GLU library, setting up and rendering a scene is simple, and if you use GLUT, GTK, or FLTK as your windowing toolkit, to 'port' it to other platforms typically requires, at most, a recompile. You can even make Mac users happy! :) (Well, I don't know about GLUT, but I'm fairly certain both FLTK and GTK have been ported to MacOS, GL widget and all.)

 
Axeman

August 16, 2000, 10:00 PM

hehe.. I agree fluffy.. Opengl is MUCH easier than D3D.. and better IMO. at least for what I've been doing..

-Joe

 
Mike Boeh

August 16, 2000, 10:56 PM

I will consider it for sure. But for now, I got 60 levels to make- which is a large task :~( But it is fun, and my xml based levels are pretty easy to manage. I have looked at some opengl alternatives already, but I am pretty deap into renderit right now.

I think it is a 2d game operating in 3d space- that's my best description I can think of...

-mike

 
Mike Boeh

August 16, 2000, 11:03 PM

I can't believe I spelled deep d-e-a-p hehe :)

 
fluffy

August 16, 2000, 11:25 PM

Mike: Are you so deep that you couldn't just reimplement it in OpenGL using the same API? Also, I understand being deep into using one particular API (be it RenderIt or D3D or whatever), but remember that you can always rewrite it later. :)

I'm not saying you should switch to OpenGL *now*, mind you. Actually, if you release a DTD and specification for your XML levels, someone else could always reimplement it in another platform for you. :) This seems like the kind of game which could possibly have such a cult following that, if you're liberal enough with the license, fans of it will do you the favor of porting it up the wazoo. Maybe even to the C64. :)

BTW, for anyone who doesn't know *why* most C64 games flashed on loading: While loading, you don't have much use for video memory. However, that video memory is a good 2K of memory which makes great tempspace which you don't even need to keep track of later...

Code. Music. fluffy.

 
malkia/eastern.analog

August 17, 2000, 12:48 AM

Well if it was written in OpenGL, then someone will come and say - whau great game (really!!), why don't you rewrote it in Direct3D, cause 2D support there is BETTER! (which is TRUE!), and why not do a SOFTWARE RENDERER and PROFILER which will detect BEST CARD to USE, and MULTIMONITOR SUPPORT, and SAFE MODE... (that's all was implemented by me four our last game port - Metal Gear Solid)... I hate DIRECT3D, but I HAVE TO program with it... what Can I DO.

Also, it seems that DX8(OpenGL??) vertex/pixel shaders will be written better in D3D style (like ASM cops). There is something for OpenGL called smashGL (or smash) something like smBegin, smEnd() stuff which is the opponent of vertex/pixel shader language of D3D. The problem really is, that XBOX will have very specific things which can't be represented by generic language form or ops. (for example after some cop or whatever or you must not get directly the result). So it depends a lot... I Still don't know what to use... In our port we were using a lot of 2D effects, and we were not sure how this will be on OpenGL (also OpenGL can't control well very deep things like BLITTING ASYNC or SYNC, WAIT, NOWAIT, DMA setups and so on.)

Except all this - I PREFFER OpenGL + GLUT + my favourite editor E 3.05 + makefile - and that's all I need....

 
Mike Boeh

August 17, 2000, 12:51 AM

My fonts are all 2d, and i do some 2d particles... I have heard some stuff about opengl being bad for 2d, but i am sure u could get around this by just mapping 2d textures on planes and making them 3d. Now if i could only code a decent looking explosion...

 
Axeman

August 17, 2000, 01:12 AM

My gui system is rendered in 2d opengl (Orthographic)... it's really not a problem so far.. actually it's easier than I thought it would be..

 
fluffy

August 17, 2000, 03:39 AM

malkia: D3D doesn't have better 2D support. You're confusing it with DirectDraw. And anyway, the days of coding to the metal and getting a direct framebuffer are (thankfully) over - DirectDraw is a very thin wrapper around hardware based on ANCIENT mentalities (sprites put onto backbuffers and copied directly from there, and so forth). With 'pure' D3D and with OpenGL, if you want 2D stuff, you put it into a texture and draw a textured quad, and you still get hardware acceleration, bilinear filtering, perfect chromakeying, and other stuff which DirectDraw can't touch (easy color filtering and automatic color conversion, for two).

If people bitch about a game not supporting D3D, tell them to bitch at their video card manufacturer for not properly supporting OpenGL.

As far as ops and bytecode and the like: that's what extensions are for. If some video card manufacturer wants OpenGL support for their shader language, they just have to submit it as a proposed extension to the OpenGL ARB, the ARB says, 'Sure, that sounds good, call it GL_NV_Shader_Bytecode for now, and we'll work up a generic form for OpenGL 1.3.' However, OpenGL, being a nice, flexible, generic, low-level language for graphics programming doesn't really NEED a shader library - just a couple days ago there was an article on here about how someone at SGI wrote a Renderman bytecode interpreter which converted Renderman shaders to OpenGL calls and gave near-realtime Renderman rendering.

OpenGL doesn't manage the low-level hardware-specific things because that's up to the driver to do, and it should be up to the user to set it up in the driver the way they like it. Also, OpenGL is network-transparent, which I know is a hard concept for you single-user Windows cripples to understand, but it's kind of hard to do vsync controls when you're not necessarily even on the same machine as the triangle setup engine which might not even be on the same machine as the raster convertor. Sorry, that's the way it is. It shouldn't have to be up to the application programmers to know how to deal with things "the best" on some particular hardware, because some new piece of hardware will come out where that's no longer the case and then their optimization hack results in nasty side-effects which break and/or slow down on newer hardware and even completely-new hardware methodologies. Like, DirectX's methodologies probably wouldn't fare too well on SMP systems (whereas with OpenGL, the driver can easily run in a separate process anyway, as is the case on both Linux and Windows NT), and things like plane rendering (PowerVR, anyone?) can be handled transparently by the hardware driver whereas in DirectX you still have to know a LOT about the hardware you're coding to. DirectX isn't any better than oldskool assembler-to-the-metal-on-a-billion-different-proprietary-video-cards, it just has namespacing in the form of COM. :P

Oh, and don't even get me started on what a bad hackjob MS's implementation of the COM spec is, either. COM just badly reimplements the implicit dynamic linking that UNIX et al have had for years at the binary-loader level.

Code. Music. fluffy.

 
fluffy

August 17, 2000, 03:57 AM

Oops. In my last sentence, I meant 'MS-COM just badly...', not 'COM just badly...'. COM itself is fine. MS-COM sucks. :)

Also, take my rant with a non-zero quantity of salt. It's way past my bedtime. :) (I'm training my pineal gland for having to wake up at 6AM on Friday for a TA orientation. Oops, too late...)

--

Code. Music. fluffy.

 
This thread contains 26 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.