I think you should use RLE images here. You''ll loose some performance, but with a strong asm routine you''ll get your hands free with the subject.

If you need just 12MB for the background, and lets say 2MB for the sprites (and their framesets), then what will be left to load sounds????

Think about it.

Another way might be to load parts of the image each time. If the user uses 800x600, you might load a screen of 1600x1600, though i''d prefer the RLE solution.

c ''ya

According to bstach, if I were to use *any* Windows functions for my memory allocation, there''s the risk of disk-swapping. So, I will probably just use my archaic dos extender code, which is ''XLIB'' by TechniLib. (like Qoy pointed out, the old dos version of my game *does* work under Windows).

Now, some of you are saying that I should just use Windows mempory alloc funtions and let it do its disk-swap thing, but I personally think this would take way too much time, even if it were only a couple megs every cycle.

Lotan and Harvester: yes, my game will probably require a machine w/ more than 16 MB. Perhaps I will start a thread about how much RAM a game should require these days. Harvester: you suggested RLE (run-length encoding). For anyone unfamiliar with this, its a way to compress images when you have long runs of a single color. Harvester, if you looked at my screenshot in one of the previous posts, I can see why you''d suggest this. However, in my current version, I plan to eliminate any flat spots in the terrain, because they look unnatural, so there won''t be any single-color ''runs''.

Ok, there have been a few SERIOUSLY wrong posts here. At least in their assumptions.

First, BSTATCH was 100% correct in his assertion that if the user does not have enough memory, than windows will move around the memory it can (must) in order to execute the program. THERE IS NO WAY AROUND THIS. By definition, a system with insufficient memory MUST use virtual memory, or stop executing (aka CRASH).

Second, you CANNOT assume you are the only program running, EVEN in full screen exclusive mode. That only ensures that you are the only DirectDraw program running. What are you going to do when the users running FTP, a Virus Scanner, or a security logging routine in the background. If you lock 70-80% of the memory, than you are going to bring the system to its knees, and this INCLUDES your program, because windows will give your program exactly the same time slice as the other programs (maybe even less if they are high priority). Even if you are the only program running, trying to detect ALT-TAB in order to deallocate memory is basically the EXACT SAME thing windows would do anyway, which is leave eveything in use in memory, and remove old data when new data needs space.

Third, you WILL NOT manually manage memory better than Windows does. Windows (and Linux, and BeOS, etc etc) manage memory using a VERY effiecient algorithm with the goal of MINIMIZING disk accesses. You can only HURT the built in memory management system by denying it the ability to move your blocks of memory. WINDOWS WILL NOT put your 12MB file on the disk unles it runs out of space. AND EVEN THEN it only move PARTS of your programs data to disk, THE LEAST USED PARTS, so that will NEVER be your 12MB block if it is used every couple of frames.

Fourth, Windows would not even have to move your whole 12MB file to disk, just because you THINK of it as a logical block. Windows sees the world in equally valuable pages, each of which are independent. So if your program is running on a computer which has 1MB too little memory, it will only swap 1MB memory to disk, and any or none of that 1MB might be your 12MB structure. Also, it will not affect you AT ALL, since windows will automatically page in memory you try to access, by LOOKING AHEAD at upcoming instructions, just like L1 and L2 memory cache, which is USUALLY BETTER than the code you would write to manage the memory.

Since Windows is running it's own thing in the background, including device drivers and scheduled applications, you can ONLY hurt your user by force locking memory. And if he doesn't have enough memory, say he has 16MB, you would be forcing his hard drive to crash MUCH earlier than normal, by thrashing everything in and out of the remaining 4MB of memory. I don't even want to imaging if you had a memory leak with little 100K blocks of unmoveable memory. Soon the users hard drive is trashing away, AND his computer is locked, a surefire way to generate bad sectors on the hard disk when the user forces a cold reboot.

NOTE: YOUR DOS EXTENDER DOES NOT GIVE YOU NON-VIRTUAL MEMORY. Windows runs each does app in a virtual space just like a windows app. Hence the reason most programs are compatible, but many low level utilities are not (they relied on EXACT non-virtual addresses). Windows will simply LIE to your program, to you it will seem unchanging, just as if you used the built in C++ memory allocation (much easier but in reality it will move anywhere windows wants.

Edited by - Xai on 3/9/00 10:43:25 PM

Why move your game to Windows if you won't let other apps run at the same time? Doesn't that kind of defeat the purpose?

Also, why allocate the memory yourself? Why not create a DirectDraw surface?

Good Luck!


- null_pointer


Edited by - null_pointer on 3/10/00 7:40:54 AM

Eric: Didn''t mean to be rude -- just wanted to point out that programming under Windows means sharing resources and using other people''s libs. It''s a whole different mindset from DOS. It''s one thing to make a great game that hogs the whole computer -- it''s quite another thing to make a great game that lets you browse on the internet for tips or chat at the same time! The possibilities are endless...

Good Luck!


- null_pointer