Hello there everybody!

I'd like to ask you on the possibilities and features of DirectX.
As I've found out, many games - many older games! (take into consideration all FALLOUT games, and some newer strategies since Starcraft, I think. Warcraft2 didn't) required DirectX.

I know it isn't just for fun that these games needed it.

Can someone who knows the features and have insight into its application to games, answer me a question?

The question is concerning tile-based games: Does DirectX - specifically DirectDraw(or so-called Direct2D) - does it extends memory of the computer for drawing up tiles and actors so that it will no longer be slow?

I am programming an isometric RTS where tiles are practically in the background, but everything else - that includes walls, actors, scenery etc. have to draw in strict sorted order - to ensure that something is before and something is behind.
And this repeatedly redrawing of the bunch of sprites slows it down a lot. Especially in larger map - let's say 100x100 or 200x200 isometric tiles of 64x32 pixels. I managed to do one thing - that the actors redraw in the visible part of the screen only (640x480 pixels) + with some extension beyond the screen.

If I have a map of 20x20 tiles - and it's almost unscrollable, it's okay. Everything is in good speed.
But in larger maps, it slows down anyway - even if it doesn't redraw all the map, just the visible part.

Therefore - will DirectX help to solve this and make it faster? Will it enhance the capability of computer to draw it faster?
Many games are like mine - isometric RPGs. And they consist of large maps.
Do I require to use DirectX or change in programming?

DirectDraw has been depreciated since directx 8. The proper way to do things now is to use direct3d and draw textured quads.

_________________
My Development Blog | My Website | My Current 3d Engine

direct x will hardware accelerate the drawing compared to other software based api, so it will be much faster depending on the current api you were using.

but it really sounds like you're poorly coding your map render functions.

i bet you're still drawing or processing things that are outside of the map viewport, and that's probably the real reason its slow.
or maybe you're doing multiple passes through your map tiles, and that was coded poorly.


what i did for my game was, i had one 'map manager', which consisted of 4 different map layers.
the map manager would draw the map layers in sequential order according to layer priority.

One thing to ensure - pardon if I wrote "RTS" - then no, it's RPG!



I'm trying to make similar progress as was Starcraft and FALLOUTs including Fallout Tactics. Good old bitmap rocks and many times 3D vectorized crispy polygonal graphics just suck. That's why many older games look better than 3D low polygon ones.
Someone may argue with me, saying: "But 3D has advanced, games nowadays are HIGH-POLY and look realistic" - maybe, but they are too expensive to be made and both difficult to be coded and also incompatible for those who haven't such nobility-class computers. I'm giving a try - a serious game for few (or no) money, not being a professional programmer (just know-how).

Only if there was a way... ... the way that Direct3D could render 2D bitmap images. Can be Direct3D used for this? Will it be faster?



Then maybe that's what I was looking for.
Did your 4 different map layers mean layers for background tiles (that needs no redrawing or change cos it's just static floor), walls, actors (that include Player character and NPCs), scenery?

I dropped all "actors - walls, NPCs, with Player Character and scenery" (except the isometric tiles) into one map list - the reason is to make sure that none of these layers redraw thru nothing.
I use a repeated loop from the most top-left (in isometric the most top tile) visible tile to the most bottom-right visible tile (in iso the most bottom) to draw everything on these positions (all visible tiles) every second.
I formerly rendered all the map over and over - it was slow.
It is faster now - my code redraws only visible part with slight extensions beyond the screen - that's only because of the tiles that are isometric and the computer screen is rectangular - so it's needed.

The loop from top "VisibleXY tile" to bottom "VisibleXY tile" is some kind of sorting. If player character is on position minus 1 or 2 Xcoordinate or Ycoordinate than some wall, it makes sure that the player will not draw across the map - so the player is behind the visible walls. And you move your player character 1 or 2 tiles after the walls, the walls will not draw across the player - that means the player is before the walls, visible.
The same with items, for example, a crate can be in same fashion behind and before walls etc.
You can say that every tile being looped from let's say: X:0 to X:20 and from Y:0 to Y:20 is a layer. That's the isometric sorting. What is on lower coordinate is behind and higher coordinate means what is before.

The background tiles need no sorting - they are pre-rendered at the beginning into one huge bitmap in memory and in the game my code just copy the visible part of 640x480 pixels (that is the resolution) from the huge tile-map image (depending on where the map is currently scrolled) every second.

Hope you understood what I was trying to say.
If you have more layers for the list of sprites than me, and it works (nothing draws over thru nothing), try to explain me how does it work and how can it be done.

Yes and yes. I wasn't suggesting that you use 3d but rather use direct3d for 2d rendering. Search for "2d in Direct3d" on google and you will find what you're looking for.

_________________
My Development Blog | My Website | My Current 3d Engine

Oh well, thanx then. I guess some games were made this way.
If we imagine Fallout Tactics, or possibly Diablo 2, they both aren't 3d based.
No models, just sprites. Still, they may use Direct3d for rendering.
Am I right?

I have looked at this site explaining this:

http://www.gamedev.net/reference/articl ... le1972.asp

And they use some "vertex format" - the way of my tiling is just 64x32 pixels, all pixel-like, all bitmap. I use no vectors, no quads - just rectangles with background color that is not pasted on the screen.

One thing to remind: Does using Direct3d require to change coding? I hope not. I was looking just for using that API to fasten the computer's processes and capablilities during the same map rendering.

I think those old games used directdraw. 3D was not very powerful in the 1990s. In the same way you can run Starcraft on Vista, it is still possible to use directdraw, but it's not the natural choice (nor the most compatible) since 3D has become the faster of the two.

One factor to consider is that when using direct3D for drawing sprites, you don't necessarily get pixels of the screen and pixels of the texture lining up perfectly anymore. Quite often it ends up resampled/antialiased whether you like it or not.

2D has the advantage that every pixel is how you want it, so you always get a sharper clearer image than 3D at the same resolution.

_________________
I ain't pushing no moon buttons.

Thanx, my always-helping Jasmine! I appreciate it!

That's just what I needed. Every pixel is important.

However, you were quite right, cottonvibes, mentioning this:



Not that I would draw the whole map, the things visible drawn are only map view around the player character - plus and minus 12 tiles in both axis.
This however, is not a problem! Even if I had 5 tiles view around the player char., it's still slow with the same "speed" - I tested it.

The problem I have is not drawing things outside of map viewport, but processing things outside of map viewport.
My smaller map that is working fine with good speed, is circa 20 x 20 tiles with 8 or some 12 objects in map.
My larger map is large 100 x 100 tiles - which isn't immediately a problem.
Problem is, that I have 600 and more objects in that map. Every wall chunk - whether it's a corner wall or south, east, west or north wall that perfectly conform to every tile, is meant to be one object.
Now imagine how many objects you can have in 100 x 100 tiled map.
10000 objects! Damn lot, isn't it?

The process I need to do, is sorting these objects to ensure that every object is drawn in correct order. But admit - it is too much for any computer to process - to sort 600 objects considering their X and Y pos in the map, isn't it?
Perhaps some change in processing would help? - sorting the objects in map viewport only? (Which is not the easiest thing as for the map is isometric, not square-like)

You may not need to process 10000 objects each frame.

You could construct a reference list of maybe 100 nearby objects, and only consider those in the tight program loop.



idx is the object reference index that runs from 1 -> 100
objectidx is the index number of the object you want to reference.

Rather than having a loop like


...you would have...


You could update the reference list only when your camera/actor moves some distance from its last position. Or alternatively, you could update the reference list continuously but in baby steps: considering maybe 50 objects per redraw, so it takes 200 frames to pass through the whole 10000, adding to your reference list whichever of those 50 are nearby to the camera, and removing those which are not.

You could also then write a subroutine for sorting that small list of 100 objects only when it has changed.

_________________
I ain't pushing no moon buttons.

Yeah, I realized that this has nothing to do with choice of dimension, whether isometric or square.
I realized that even in my 2D square-tiled "Snow Wars", formerly posted to you, having more than twenty or thirty objects in whole map (but that was rather whole map processing I think), had resulted into slowdown.

I wonder how did they made games like Dune 2000 (the same principle 2D square-tiled RTS) or Starcraft, without problems of slowdown, no matter how many objects you have in map. - cos in Dune 2000, you can train and train new units, have vast armies thru whole map and still it doesn't slowdown.

I guess there's needed some modification of processing whole maps including all data within.

The thing I do concerning drawing, is having terrain linear lists of numbers - it's classical method of tiling - each tile type has specific number, while the unit data in map is rather more complicated - but it has to be complicated, cos units need to carry far more data than terrain tiles.

My unit data list is number of lists within one list. Each of these lists within are whole units with all data they carry. most of it are dynamic data, cos they have to change during the game.
Main of these are X and Y positions (tile positions in map).

And now the problem I have is that I can't avoid looping the whole unit list to locate what should be drawn where in viewport display - the current display where you are currently scrolled in map. You still need to check what if the last unit with number 100 or 200 is located in top-left corner, which would have 0,0 - X,Y positions.
Of course it needs to be drawn if we are in viewport in which you can see position 0,0 - the top-left corner.

Are that, Jasmine, what you have posted, lesser loops within one loop?
100 loops and in each idx= 1 to 100?
And would that be faster than from 1 to 10000 for computers?
plus, concerning the baby steps processing, would not there be some delay visible in the units on the display during those 200 frames in those 50 objects per redraw?

I guess that would mean that my unit - 100-th unit in unit list, located at 0,0 would be processed last. Am I right? Or.... ...is it a matter of computer memory how many objects it can process at once?
I don't know these principles.
What is too much for computer, resulting in slowdown and what is without any delay?

They must have had done Dune2000 map processing somehow without any delay. But how?
Maybe pre-loading and loading maps on starting that takes some time, fixes this?
How then to preload it all and what if new units arrive that weren't formerly on the map from the start - and so no preloading occured upon them?

Jasmine:


But that's practically all the time, even movement of one unit from that list means change of the list, or not?

The PC was never originally designed for graphical performance. It wasn't until the 32-bit era in the mid 1990s that performance graphics began to happen. The graphics on other 16-bit computers before that time was superior than anything on the PC.

Most PC games in the mid 1990s would be run in DOS, and not in Windows. And in DOS there were special screen modes that could be used. One of these is mode 13h, which offers 320x200 pixels with 256 colours. This fitted nicely into a 64kB chunk of memory, which was stored in the processor's cache, so programmers could draw to those pixels extremely quickly. So much so that the whole screen of pixels could be redrawn in real time, and fast enough to make a full screen game.

Before graphics cards became mainstream, programmers would use the processor's own Block-transfer instructions to draw things to the screen. This is an operation which quickly moves large chunks of data in memory.

When graphics cards came along, they had their own block transfer functions, which is what you access with DirectDraw. It allows you to move chunks of picture around in graphics memory, say for drawing a sprite. This was quicker than getting the cpu to do it, and it worked with the larger screen resolutions and colour depths that graphics memory was designed for.

Even though modern computers are faster, consider that modern screen modes are around 25 times the area and 4 times the colour depth of DOS screen modes, which is 100 times the amount of data to move around. It has always been and still is generally better to work out what not to draw, than just to draw everything.

For example, rather than draw lots of overlapping sprites, you could draw only the parts which are visible, which means using logic to determine which bits are overlapping.

Always ask yourself "Given that I have this screen image, what could I get away with not drawing into the next frame?"

The programming language you are using may also be responsible for general slowness.

_________________
I ain't pushing no moon buttons.

Thanx

...or perhaps it is a failure of my coding, or solving data structure.
I need some new style or method how to get all unit data.

Working in Macromedia Director MX (its programming language is called Lingo, while ActionScript belongs to Flash), i have always used an array list with properties, so-called property list(i don't know if there's same thing in other languages)

as you can see, scroll down or find CTRL+F "Using List Variables" there are 2 types of array lists - linear and property lists

http://www.informit.com/articles/articl ... 1&seqNum=3

- and that may be the thing that i got stuck in.

I thought it easy to use one list with brackets [], which contains as many property lists as there are units in map - each property list is a unit.

And now, if I wanted to access any of the units, I needed to do loop for all the list (which contains all units) to locate it.

(variable) UnitMapList = [[#number:1, #unitname:"raider"...],[#number:2, #unitname:"tank"...]...etc.]

(loop) Repeat with A = 1 to count(UnitMapList) -- all entries in the list (all units)

NeededUnit = UnitMapList[A]

or

WhichUnit = UnitMapList[A][#number]

End Repeat

...only then I could make any other operations with it, so it looked like this

Xposition = UnitMapList[A][#XPos]
Yposition = UnitMapList[A][#YPos]

However, than means loop of all units, which is problem if there are hundreds of it.
I guess there could be more reasonable solution, couldn't it?
Some text document with strictly organized lines, words and letters...
And then just use program Find char or word or letter that contains... whatever... sometimes, bureaucracy can be useful

What method of data management do RTSes use? Do they use just text in organized form?

ElectroPalladin, do you still need help with this, or did you figure out a solution? I was going to write a reply to this, at some point, but I completely forgot about it and just remembered when I saw this thread again.

_________________
Worlds at War (Current Project) - http://www.awkward-games.com
Ganadu'r, The Eternal Sage (Other Current Project) - http://rpg.naget.com
Programming tutorials and web-design services: http://www.wyrmmage.com

Sure, some help would be appreciated, mainly if U understand this topic. Isometric RPGs maps use many objects. In Fallout 1, the maps can have let's say hundred and more objects (and that include characters, items, scenery, walls, everything except floor and roof tiles), and by no means is it slow, even if they somehow need to be sorted if the objects move one thru another, when it makes difference if objects are behind some chunk of wall or in front. The things in front are drawn the last, after those behind. But without processing I guess it's impossible.