Tile Engine Problems with Video Memory

Tommaso · 03-04-2003, 10:17 PM

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!

jdinger · 03-04-2003, 10:31 PM

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?

Tommaso · 03-04-2003, 10:42 PM

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.

jdinger · 03-04-2003, 11:02 PM

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 jason@skylockgames.com 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.

Tommaso · 03-04-2003, 11:14 PM

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.

frenchfry164 · 03-05-2003, 06:09 PM

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.

Tommaso · 03-05-2003, 06:23 PM

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!

**Bubba** · 03-06-2003, 07:18 PM

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.

frenchfry164 · 03-07-2003, 08:26 PM

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.

03-04-2003, 10:17 PM	#1
Tommaso 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!
Tommaso is offline

03-04-2003, 10:31 PM	#2
jdinger Used Registerer 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?
jdinger is offline

03-04-2003, 10:42 PM	#3
Tommaso 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
Tommaso is offline

03-04-2003, 11:02 PM	#4
jdinger Used Registerer 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 jason@skylockgames.com 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.
jdinger is offline

03-04-2003, 11:14 PM	#5
Tommaso 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
Tommaso is offline

03-05-2003, 06:09 PM	#6
frenchfry164 Banned Join Date: Oct 2001 Posts: 1,552	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.
frenchfry164 is offline

03-05-2003, 06:23 PM	#7
Tommaso 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
Tommaso is offline

03-06-2003, 07:18 PM	#8
Bubba Super Moderator Join Date: Aug 2001 Posts: 7,819	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.
Bubba is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

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