Hello... I just read the 2D rendering in DirectX 8 article on this site...good stuff, but a little over my head (esp. the matrices and such, since I know less than nothing about 3D). I did a little research of my own, and saw some posts about using the ID3DXSprite interface instead of textured quads, transforms, etc. Since I don't have enough of a grounding in matrices (soon, I hope, that'll change), the ID3DXSprite interface sounded like a good idea...except I can't find a good tutorial to get me off the ground. Any ideas? While we're at it, another, somewhat less programming-oriented question: How exactly is scrolling done? In terms of what's loaded when, how it's drawn, etc., not how to program it, that is. (Just in case I didn't word that right, I mean scrolling like running to the right in Super Mario ) One last thing (and I know this is the DX forum, but...): would OpenGL do any better at 2D (in terms of programming ease), or is it in the same boat as DX? (I only ask out of curiosity... my system's OGL support blows so much, it'd be hopeless as a development platfom ) Much thanks for your time, keep up the good work, and all that! -Normie PS. If anyone uses that last question to start a DX vs. OpenGL flame war, then may French soldiers "...fire arrows into your heads and make castanets out of your testicles already!" "But time flows like a river... and history repeats." ... So...what about beaver dams?" Edited by - normie on August 4, 2001 1:47:14 AM

Hi,

The code in the article should shield you from matrices once you write the wrapper functions...

About the Sprite interface - I''m sure someone here will point you to the sprite wrapper done by another member of this board. The purpose of the 2D article was to show what was happening under the hood in the sprite classes. The only advantage of the article method over the sprite stuff is that you may have better control/optimization/understanding by having access to the guts. Which brings me to your next question...

One way to do scrolling would be to load some textures, draw some quads, and move those quads sideways with each frame. Another way could be to animate the texture coordinates so that the texture itself slid over a stationary quad (here''s where having your own class comes in handy..). Probably about the same performance wise, although there might be better/worse ways depending on your exact requirements.

About OpenGL. The method described in the article is really adapted from OpenGL code because the OpenGL 2D functions are extremely slow on most hardware. In OpenGL, you do fast 2D by using the fast 3D pipeline, same as the article. In fact, if you sat down with the OpenGL red book and the 2D article, you could probably "port" the article code to OpenGL pretty quickly, even if you don''t know OpenGL.

My two cents about OpenGL - I used to say that OpenGL was the better beginner''s API because it was alot easier to deal with than DX7-. However, if you''re careful with your interface pointers, DX8 is almost as easy. Having said all that, if you''re at the point where matrices are confusing, you may want to play with OpenGL... Another suggestion - use DX8, but pick up the OpenGL red book. I think it has great, concise explanations that will help you with the concepts and it''s pretty easy to translate the concepts and simple code into the DX8 equivalent. From a learning perspective, there are pros and cons to both, and most of the religious wars are silly - take a gander at both and see which one has the better resources for you to learn from. Once you know one, it''s really easy to switch to the other later on (from a mental perspective, not source code). Much like a good C++ programmer moving to Java and vice versa.

More pontification:

Microsoft screwed up a little bit in that they introduced the notion of "DirectX Graphics" as an overall graphics API, but then retained the "Direct3D" moniker, leading everyone to woefully lament the lack of a 2D interface.

"3D" naming issues aside, "DirectX Graphics" is just like "OpenGL (Open Graphics Language)" - it''s an API to a piece of graphics hardware. "Graphics" implies 2D as much as 3D, and going forward you''ll be better off using the full graphics pipeline.

Once again, I leap down from the soapbox...

Thanks for the help...couple of points, though:

1. I''d use DX7 and DDraw, except it just wouldn''t feel right to me to learn an older API. Just how I am, I guess.

2. I did a little research on moving stuff on screen, and I mostly figured out the answer to my scrolling question. Thanks anyway (By the way, when I said scrolling, I meant things like the background moving while your character stands still to simulate movement).

3. My first game (if I ever get that far) will be a Tetris clone; after that, a Super Mario clone. I think I can do the Tetris one, but I''m a little puzzled on an aspect of the Mario one: namely, creating and loading maps. I figure I''ll have to make another program to create maps, but I have no idea how to get started on that (not that I''ll start it anytime soon). Any tutorials on this sort of thing available anywhere?

Thanks again!

-Normie

"But time flows like a river... and history repeats."
...
So...what about beaver dams?

I know DDraw would be faster, and probably easier, except for two things:

1. I don''t like learning old technologies (despite the fact that DDraw 7 is the newest implementation of DDraw...but I digress)... again, no real reason, just the way I am

2. Far as I can figure, despite the 2D-ness of it all, a 2D program in D3D 8 is still 3D... sounds like a good opening for special effects, if I ever get that far along.

-Normie

"But time flows like a river... and history repeats."
...
So...what about beaver dams?

Hmmm...

I don''t think MS recommends DirectDraw anymore, except maybe in the case where you would want to support older hardware. But then again, I''ve been wrong before...

At a guess - I''d say that if you are trying to draw 2D "the old way" (lock the buffer, Blit, etc.), then DirectDraw might be faster than doing a lock/update/unlock in the DX8 world. But, if you''re doing it the 3D way, I would guess that the 3D speed would be equivalent or even faster (than the equivalent directdraw calls) on newer hardware that is very 3D pipeline optimized. Plus, you get all the fun stuff like better texture manipulation.

One thought - if you are writing a 2D game that you want to run on any old hardware, then you are probably better off in DX7. If you are writing a Tetris clone as a learning exercise on your hardware, then I would say to learn DX8.

quote:Original post by Anonymous Poster
But, is there still a market for the 2D game of any kind? Today, if *you* saw a game that didn''t require 3D acceleration, would you want to buy it?

Absolutely. "Requires 3D acceleration" does not equal "good game"; neither does one imply the other. But I guess I''m strange and of no consequence to the "big boys" of the "video game industry" *washes mouth out with scotch*

I have more than a little irritation with games lately. And, yes, 2D games (or 2D "with 3D effects", whatever) are still quite popular. They typically have better graphics, and by this I mean crisper, cleaner images. Plenty of top-sellers are still primarily 2D. I hope it stays that way for quite a while, but, even if it doesn''t, I''ll program primarily in 2D, and to hell with being a "top-seller". I''d be happy if fifty people bought my game. I''d be happy if nobody bought my game, as long as I liked it, and as long as I knew it was better than the llama-spew I walk by at GameStop or CompUSA.

Incidentally, my favorite Playstation game is still Castlevania: Symphony of the Night. Guess what? 99.9% 2D. The smatterings of 3D in C:SotN could have been produced using the SNES'' "Mode 7" effects. And it was an excellent and highly-praised game. I can only wish for more quality games like it.

If you let the market decide what you want, then you''ll get exactly what you want.

---
blahpers