Tile Engine Problems with Video Memory

Hello everyone. I was wondering if anyone out there can help me with a tile engine problem I have been having. Usually when I run into a problem I keep at it myself until I figure it out, which has worked out pretty well until now. For a week I have been trying to figure this out and my patients is at an end. I have designed a overhead square tile engine with direct X which works beatifully, with the exception that it's scrolling is very slow. I used Directx clipper function, which is what slowed it down. To improve the speed I changed my bit blits from system memory to video memory, and this makes the speed satisfactory. The only problem is is that the bit blits don't appear as there suppose to. I only get half the image, or close to it, with the remainder of the bit map black, so that I get a zebra pattern. I assure this is because my video memory on my graphics card is non-linear. How do I fix this problem.? I might be wrong about the non-linear thing. It is just a guess on what I have been reading. Can anyone shed some light on this setback. Im almost finished, and am anxious to get started on the actual game. Thanks for your help!

Are you using DX fullscreen or windowed? If it's fullscreen then you don't want to use the clipper.

As for what you're getting, it sounds like garbage from the video card from an incorrect RECT size maybe. Are you using Blt or BltFast? Are you clearing the backbuffer between frames? And if so, how?

I am using full screen, and I am using the clipper. Should I do my own clipping? The rect size was correct when I used system memory, it only changed when I switched to video memory. Would that influence my rect size? I am clearing the back buffer every frame. With clipping turned off it works great, but I get unacceptable disappearing blits at the outer edges of the screen when I scroll that makes it look very amateuristic (well, I guess I am an amateur, but would like to avoid it as much as possible). Any suggestions? Oh ya, I don't know if this will help at all but the world size is 8 screens by 8 screens, and at 600 X 800. Just thought it might help.

I definitely recommend doing your own clipping. Basically you test the current sprite's map location against the view space and verify if it's on screen. If it is then you do your clipping by testing to see if it's defining rect is clipped by the view space and make adjustments to the rect that you blit.

If you want to see how it's done send me at [email protected] and I'll send you the excerpts from my tile engine (which is complete with it's own clipping.

Using a clipper on a fullscreen DX game is not necessary and it will cause tremendous performance hits.

As for why you're getting garbage I'd have to see your code as well as the sprite's *.bmp to see where the bug is.

I will get things together tomorrow as it is getting late, and will send them to you so you can look at the code. I appreciate any help you can give me. Thanks again for offering to look at it. I greatly appreciate it.

A good way to do it without checking each for if tiles are on screen or not, is to draw an extra row/column on each side of the screen.

Maybe you need to wait for V-sync? I severely doubt you do. I haven't used DX b4, so I don't know if this is a problem with it.

V-sync, I never thought of that. I think that might be what it is. I'll go over my code and report back - thanks!

If you know assembly you can use it to speed up your blits. This sounds very strange, I know, but it seems to me that in my tile engine and my other 2D ventures that the hardware blitter was slower in some instances than pure assembly code. I'm not sure why since my theory for using the hardware blitter in the first place was that hardware was faster than software, but apparently there is more to it than that because it simply is not true in this case, or at least in my limited experience.

I would try it both ways. To make it easy first try to clear the surface using the hardware blitter and just blit a huge black box to the surface. Then try the same thing in assembly and profile it. This really would be the only way to tell which was faster.

I think this is the code for the blit. This is not a filled rectangle blit - it is really just a 32-bit memcpy

Code:

---

_Copy32    proc
ARG  Source:DWORD,Target:DWORD,Length:DWORD

    push  ebp
    mov    ebp,esp
    push  ds
   
    mov    eax,Source
    mov    ds,eax
    xor      esi,esi

    mov    eax,Target
    mov    es,eax
    xor      edi,edi

    mov    ecx,Length
    rep      movsd
   
    pop    ds
    pop    ebp

    ret
_Copy32      endp

---

Buffer and Source will be your surface pointers. DirectX will allow you to access these pointers. This code might be lengthier than need be since you may not need to load the segment registers since you are in protected mode - sorry, I really just do not remember. I've become a bit rusty on my 32-bit assembly - I will look at my engine code (sorry, I'm not on my system right now) and get back to you.

Also if you do not use the hardware clipper you will notice a significant speed gain as the others have stated. The only way to tell where the slow down is coming from is to profile the code. It might not be slowing down where you think it is and then again, maybe it is. The profiler will eliminate the guess work.

There will be a inherent slow down here, though, since you must lock the target surface before you can blit to it.

I will do some research for you on this subject and get back to you. Sorry I cannot help you more at the moment.

Quote:

---

I'm not sure why since my theory for using the hardware blitter in the first place was that hardware was faster than software, but apparently there is more to it than that because it simply is not true in this case, or at least in my limited experience.

---

This may be just the graphics card you are on.