Thread: Tile Engine Problems with Video Memory

  1. #1
    Registered User
    Join Date
    Oct 2002
    Posts
    118

    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!

  2. #2
    Used Registerer jdinger's Avatar
    Join Date
    Feb 2002
    Posts
    1,065
    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?

  3. #3
    Registered User
    Join Date
    Oct 2002
    Posts
    118
    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.
    "The distinction between past, present and future is only an illussion, even if a stunning one."
    -Albert Einstein

  4. #4
    Used Registerer jdinger's Avatar
    Join Date
    Feb 2002
    Posts
    1,065
    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.

  5. #5
    Registered User
    Join Date
    Oct 2002
    Posts
    118
    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.
    "The distinction between past, present and future is only an illussion, even if a stunning one."
    -Albert Einstein

  6. #6
    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.

  7. #7
    Registered User
    Join Date
    Oct 2002
    Posts
    118
    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!
    "The distinction between past, present and future is only an illussion, even if a stunning one."
    -Albert Einstein

  8. #8
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    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.

  9. #9
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Assignment Operator, Memory and Scope
    By SevenThunders in forum C++ Programming
    Replies: 47
    Last Post: 03-31-2008, 06:22 AM
  2. Tile Engine Scripting Idea. Suggestions?
    By napkin111 in forum Game Programming
    Replies: 8
    Last Post: 07-28-2003, 02:01 PM
  3. Need lots of help with tile engine
    By VirtualAce in forum A Brief History of Cprogramming.com
    Replies: 0
    Last Post: 06-12-2002, 01:54 AM
  4. Memory Allocation/Freeing Problems
    By Unregistered in forum C Programming
    Replies: 6
    Last Post: 05-29-2002, 08:50 AM
  5. Ascii conversion problems with dynamic memory
    By Butters in forum C++ Programming
    Replies: 2
    Last Post: 01-29-2002, 12:22 PM