[Info] Freeing Up Memory - A Must Read!

Wolf3d Code & Tutorial Development Area

Moderators: Andy_Nonymous, Adam Biser, BrotherTank

User avatar
Ripper
Code Master - Developer
Code Master - Developer
Posts: 527
Joined: Sat Mar 15, 2003 7:39 pm
Location: Germany

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Ripper »

Great work, Chris :mrgreen:
That's really a cool mixture!

I wonder how far we'll be able to go there.
And with Haasboy's changes we hit the 10000 byte mark! :shock:

I'm just overwhelmed *g*
I'll continue searching for memory saving stuff after Monday, when I wrote another exam *beingboredfromallthelearning*

Oh, btw, char values go from -128 to 127 ;)
User avatar
BrotherTank
Forum Administrator
<b>Forum Administrator</b>
Posts: 2203
Joined: Sat Mar 01, 2003 4:34 pm
Location: Ontario

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by BrotherTank »

Haasboy wrote:Wow 7808 bytes freed, but I managed to free up 10534. This was acheived by doing everything that was mentioned above. I used WSJ offset code for all the enemies (i.e. they all use the same statetypes for standing, patrolling and chasing), that saved me another about 1500 bytes.
Yep... that's where I got a big chunk of memory for Advanced. It was funny to see WSJ's tutorial on it posted after I had already figured out how to do it for my own source. Although, to convert it for all guards (gaurds, ss, officers, dogs, and mutants) requires a little more tweaking as you have to make changes to the different statetype changes in wl_state.c file. And then when you add new enemies to the code, it doesn't affect the amount of free memory you have much... (other than by the code entered to add the new enemies).

@Ripper & Chris... One thing that I haven't done yet, but am looking at is... The SIGNON.OBJ and converting it to an actual BMP... Inserting it into the Vgagraph file..... and calling it the same as the rest of the images are cached in and out. I figure that even though the memory is somewhat recovered from the drawing of the image, it still must use some memory as it is part of the program itself in lines of code.

Greg
BrotherTank
User avatar
Ripper
Code Master - Developer
Code Master - Developer
Posts: 527
Joined: Sat Mar 15, 2003 7:39 pm
Location: Germany

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Ripper »

BrotherTank wrote:I figure that even though the memory is somewhat recovered from the drawing of the image, it still must use some memory as it is part of the program itself in lines of code.
You won't get any memory from there, as far memory is used for it and the memory is given to Wolf's memory manager after usage (see WL_MAIN.C SignOnScreen(): MML_UseSpace(...))
User avatar
BrotherTank
Forum Administrator
<b>Forum Administrator</b>
Posts: 2203
Joined: Sat Mar 01, 2003 4:34 pm
Location: Ontario

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by BrotherTank »

While I understand the memory is cleared of the array... or should be via the routine that you mentioned (I was saying that even thought the memory is somewhat recovered - ie using that routine)... the code itself is still part of the exe.. thus it may still take up some memory.... At least that was my theory... I guess the only way to find out is to actually do it and compare the results....

Greg
BrotherTank
User avatar
Ripper
Code Master - Developer
Code Master - Developer
Posts: 527
Joined: Sat Mar 15, 2003 7:39 pm
Location: Germany

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Ripper »

OK, it's time to continue this thread a little bit ;)

Here we go: :mrgreen:
  • Replace a stupid pc speaker multiplication table:
    Remove the "pcSoundLookup" table definition and its initialisation in SD_Startup() ("pcSoundLookup[i] = i * 60;" and the line above) in ID_SD.C and the "EXTRN pcSoundLookup:WORD" declaration in ID_SD_A.ASM and replace "mov bx,[pcSoundLookup+bx]" and the line above by "imul bx,60" in the DOFX macro definition in the same assembler file.
    Result: 510 bytes near and aprox. 32 bytes far memory
  • Unused arrays: Remove the "tracks" and "mytracks" array definitions in ID_SD.C
    Result: 340 bytes near memory
  • In ID_VH.H and WL_DEF.H set "NUMLATCHPICS" from 100 to 46 as only 46 are used in standard wolf
    Result: 108 bytes near memory
  • Unused functions: In ID_MM.C remove the follorwing functions: MML_CheckForXMS(), MML_SetupXMS(), MML_ShutdownXMS(), MM_ShowMemory(), MM_DumpData()
    Result: 152 bytes near and aprox. 1776 bytes far memory
That will do it for the second time :mrgreen:
Now I'll start doing what I originally wanted to do with the source *playingaroundonsomethinginteresting* :secret:

PS: OK, just as I thought :mrgreen:
You can quite easily improve the supported sound quality of the digital sounds by going to the SDL_StartSB() function in ID_SD.C and replace the 7000 in "timevalue = 256 - (1000000 / 7000);" by another value.
The 7000 is meant to be 7KHz but is in fact 7042 Hz and not 6896 Hz as said on some other sites (if I'm not wrong. I wonder where this 6896 Hz value comes from...).
So if you replace this 7000 by say 14084 (or just 14000 it'll result in the same because of rounding errors, but 14084 is the correct value for a wave programm), Wolf will shout the digital sounds at 14KHz!
I didn't really play around enough with samples to see, where the memory/quality factor is at best, so just play around with the sample rate (btw, ChaosEdit currently only supports importing sounds at 6896 Hz, but will be able to import at any given rate in the next version)
User avatar
Chris
DieHard Wolfer
DieHard Wolfer
Posts: 2279
Joined: Wed Mar 12, 2003 1:03 am
Location: Canada

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Chris »

Nice info Ripper. I've eagerly plugged in your findings (except for the sample rate thing, which could be fun to play around with; but I just noticed it added to you post). I like the stuff you seem to consider, as it's always things that don't have any noticable effect on the game. The PC sounds still work great with the code changes/removal. I almost forgot how cool some of those PC speaker sounds were (back before we had any kind of Sound Blaster compatible card); great stuff. There was one thing that threw me off a little at first, but then I realized that those sections had a "#if 0" around them anyways. :)

I tried a few more things lately too. One easy way to save around 2000 more free near bytes (though it subjective to personal preference, I can see how anyone might want to keep them) is to replace the Quit messages in the ID files with two letter abbreviations (somewhat like was done in EoD), and just keep a table so people could tell what the errors are for later. I might change a few more; as I want to preserve some of the more popular WL_*.C ones. Here's how it goes so far:

http://www.canadianphilatelics.com/chok ... itinfo.txt

Maybe turning the Quit(char *error) into far memory could work too, having the errors as external strings. Would be interesting to try sometime. There's a few text messages that are never used in the full version 1.4 either, so you can put #ifdef UPLOAD and #ifndef GOODTIMES on them (like the shareware message, and the don't distribute message) to save some room.

I found one easy way to bomb out with the "Out of Memory" error today (could be good for testing purposes). Just run Episode 1 with the debugging codes on, with your screen two notches less than full (viewsize = 17), then press LSHIFT-ALT-BACKSPACE, then warp to level 10, and let the SS kill you. Works every time on this machine, or atleast it will keep sizing your screen down after each attempt until you eventually get bombed out. Not sure how much more memory could be added or preserved for that kind of "Out of Memory" situation yet, but knowing how to bomb the game out in that manner is a nice start. I added a CP_SaveGame(1) tag so that it saves your game right before it bombs out; just for kicks, and it actually seems to work well - lol.

Hrmm, even though I have 12466-15042 near bytes free, I still have a desire to do something crazy with spotvis, like putting it as block 255 (FF) in the tilemap (since it just replaces floors, which is always 0); then changing all the checks for tilemap and spotvis to work for both accordingly. I think the main problem with this would be the doors, maybe making them 254 might work; or always visable. It's pretty fun to try and consider the possibility, it'll help me learn some ASM in the process.

Anyway, I'm going to stop babbling now. Have fun with your "playingaroundonsomethinginteresting" stuff man. ;)
User avatar
Haasboy
DieHard Officer
DieHard Officer
Posts: 595
Joined: Wed Jul 23, 2003 5:43 pm
Location: South Africa, Johannesburg

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Haasboy »

Another way to free even more is by using the Japanese code for the WL_TEXT file. The Japanese code is also included in that file. I have messed around with it yet.
User avatar
Chris
DieHard Wolfer
DieHard Wolfer
Posts: 2279
Joined: Wed Mar 12, 2003 1:03 am
Location: Canada

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Chris »

Chris wrote:I found one easy way to bomb out with the "Out of Memory" error today (could be good for testing purposes). Just run Episode 1 with the debugging codes on, with your screen two notches less than full (viewsize = 17), then press LSHIFT-ALT-BACKSPACE, then warp to level 10, and let the SS kill you. Works every time on this machine, or atleast it will keep sizing your screen down after each attempt until you eventually get bombed out.
When walking to work, I was thinking about this situation, and realized that this error wasn't universal, even though it worked on both the original exe and a new one. I'm pretty convinced now that it bombed with "Out of Memory" because I made a custom AUDIOHED file beforehand (shifting all the songs 4 bytes ahead); which I just totally forgot about. E1L10 was probably a little funky because it uses the first song (which is now being directed to the zeroith song in that hexed Audiohed; and the data for that non-existant "song" probably gives out invalid or out of range instructions). Heh, neat.
User avatar
Chris
DieHard Wolfer
DieHard Wolfer
Posts: 2279
Joined: Wed Mar 12, 2003 1:03 am
Location: Canada

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Chris »

I never really noticed this until last night, but those stereo tables in WL_GAME.C have a lot of unrequired data. If you want to save another 896 752 near bytes, you can try replacing the leftchannel[] and rightchannel[] arrays with something like this:
#define ATABLEMAX 9
byte stereotable[ATABLEMAX][ATABLEMAX * 2] = {
{ 8, 7, 7, 7, 7, 7, 7, 6, 0, 0, 0, 0, 0, 1, 3, 5, 8, 8},
{ 8, 7, 7, 7, 7, 7, 6, 4, 0, 0, 0, 0, 0, 2, 4, 6, 8, 8},
{ 8, 7, 7, 7, 7, 6, 6, 4, 1, 0, 0, 0, 1, 2, 4, 6, 8, 8},
{ 8, 7, 7, 7, 7, 6, 5, 4, 2, 1, 0, 1, 2, 3, 5, 7, 8, 8},
{ 8, 8, 7, 7, 7, 6, 5, 4, 3, 2, 2, 3, 3, 5, 6, 8, 8, 8},
{ 8, 8, 7, 7, 7, 6, 6, 5, 4, 4, 4, 4, 5, 6, 7, 8, 8, 8},
{ 8, 8, 8, 7, 7, 7, 6, 6, 5, 5, 5, 6, 6, 7, 8, 8, 8, 8},
{ 8, 8, 8, 8, 8, 7, 7, 7, 6, 6, 7, 7, 8, 8, 8, 8, 8, 8},
{ 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8}
};
Then go down to this line:
	leftchannel  =  lefttable[x][y + ATABLEMAX];
	rightchannel = righttable[x][y + ATABLEMAX];
And replace it with this:
	leftchannel  = stereotable[x][8 - y];
	rightchannel = stereotable[x][y + ATABLEMAX];
I'm sure it can be compressed even further, using a calculation to replicate the patterns in the table (looks like it pushes outwards like an oval from the top center, with another inverse circle-like shape at the right trying to push everything closer to 7). Maybe I'll play around with this pattern later to see if I can get some kind of exact calculation. This could be fun. :)
Last edited by Chris on Mon Jun 20, 2016 6:50 pm, edited 2 times in total.
User avatar
Ripper
Code Master - Developer
Code Master - Developer
Posts: 527
Joined: Sat Mar 15, 2003 7:39 pm
Location: Germany

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Ripper »

Good work! I always thought this to be quite oversized, but was too stupid too see how to reduce it :mrgreen:
But I don't think that you'll find an "easy" function to calculate this exactly. Perhaps an aproximation would be enough (being not too aproximative of course :mrgreen:)
User avatar
BrotherTank
Forum Administrator
<b>Forum Administrator</b>
Posts: 2203
Joined: Sat Mar 01, 2003 4:34 pm
Location: Ontario

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by BrotherTank »

@Ripper and Chris:

That code provided works great. The last set of numbers that I reported in Advanced were:

Core:[tab]9936
Far:[tab]287008
Total: 296944

And now after adding the changes from the last two posts:

Core:[tab]11680
Far:[tab]287024
Total: 298704

And with Ripper's Cloudy Sky Enabled:

Core:[tab]11600
Far:[tab]219552
Total: 231152

I gained quite a bit of free memory with those changes as you can see. And even with the cloudy sky enabled, it's still quite respectable memory wise. Game plays fine - No problems.

@Chris: There is no real noticable difference using your new stereo table. I listened very intently and everything sounded normal.

Greg
BrotherTank
User avatar
Haasboy
DieHard Officer
DieHard Officer
Posts: 595
Joined: Wed Jul 23, 2003 5:43 pm
Location: South Africa, Johannesburg

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Haasboy »

I'm currently getting two different amounts that show free space I have in my source codes for TFT. Using the following code that I got from BT merging enemies tutorial:
	clrscr(); 
   	printf("Core Memory Remaining: %lu bytes\n", (unsigned long) coreleft()); 
   	printf(" Far Memory Remaining: %lu bytes\n\n", (unsigned long) farcoreleft()); 
   	printf("                      -----------\n"); 
   	printf("    Total Free Memory: %lu bytes\n\n", (unsigned long) coreleft()+farcoreleft()); 
   	sleep (2);
When I start the game it says that I have 17344 bytes free, but when I use MCS method I calculate 15346 bytes free, I'm not sure which is correct. Here's the end info of the MAP file so you can see for yourself.
MORE INFO ABOVE
......
 3823:B276       _bordercolor
 3823:B278       _ylookup
 3823:B408       _linewidth
 3823:B40A       _pelpan
 3823:B40C       _bufferheight
 3823:B40E       _bufferwidth
User avatar
BrotherTank
Forum Administrator
<b>Forum Administrator</b>
Posts: 2203
Joined: Sat Mar 01, 2003 4:34 pm
Location: Ontario

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by BrotherTank »

Haasboy wrote:I'm currently getting two different amounts that show free space I have in my source codes for TFT. Using the following code that I got from BT merging enemies tutorial:
	clrscr(); 
   	printf("Core Memory Remaining: %lu bytes\n", (unsigned long) coreleft()); 
   	printf(" Far Memory Remaining: %lu bytes\n\n", (unsigned long) farcoreleft()); 
   	printf("                      -----------\n"); 
   	printf("    Total Free Memory: %lu bytes\n\n", (unsigned long) coreleft()+farcoreleft()); 
   	sleep (2);
When I start the game it says that I have 17344 bytes free, but when I use MCS method I calculate 15346 bytes free, I'm not sure which is correct. Here's the end info of the MAP file so you can see for yourself.
MORE INFO ABOVE
......
 3823:B276       _bordercolor
 3823:B278       _ylookup
 3823:B408       _linewidth
 3823:B40A       _pelpan
 3823:B40C       _bufferheight
 3823:B40E       _bufferwidth
Ah yes... the difference... The number given in the wolf3d.map file is a number generated by the compiler. The number given by the code is the actual memory usuable before any data is generated by the code (in actual usage). The number given by my code is what your actual exe can see memory wise, so I would be using that as the reference number.

This difference could also explain the problem that MCS found with EoD. He found that even though the wolf3d.map file still said he had room, he ran out of string space and adding 1 single character to a string created the problems that we experienced. ie: Lets say the original string was: "beta" and he changed it in the release to "final"... So the difference in the string length was 1 more character, and that what was causing the Level 11 problem. Click Here to See MCS's report.

Hope that helps...

Greg
BrotherTank
User avatar
Haasboy
DieHard Officer
DieHard Officer
Posts: 595
Joined: Wed Jul 23, 2003 5:43 pm
Location: South Africa, Johannesburg

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Haasboy »

Thanks for clearing that with me, as I wasn't sure which number I should be watching. Now I don't have to open the .MAP file to see how much space I have left.



Thanks a lot BrotherTank :mrgreen:
User avatar
TexZK
DieHard SS
DieHard SS
Posts: 369
Joined: Sat Feb 07, 2004 7:24 pm
Location: Northern Italy

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by TexZK »

What a Topic!!! I think this is one of the most useful ones!!!

Good work, boys!!!

Another change: in "WL_MENU.H":
typedef struct {
		int active;
		char string[36];
		void (* routine)(int temp1);
		} CP_itemtype;
Change "string[36]" into "*string".
Change also "int active;" into "byte active;".
User avatar
wolf3dbreaker
I am Death Incarnate
I am Death Incarnate
Posts: 196
Joined: Tue Jun 10, 2003 5:08 am
Location: Philippines

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by wolf3dbreaker »

I need some help here!

I used all the techniques that were said here (except for the one made by Adam Biser) and
now, my TC just crashes out for no reason every now and then. I couldn't even see the error message in it.
Does anyone have an idea about this?
Gone from the community for a while. Will be back on July
User avatar
Haasboy
DieHard Officer
DieHard Officer
Posts: 595
Joined: Wed Jul 23, 2003 5:43 pm
Location: South Africa, Johannesburg

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Haasboy »

Did you test your engine after each change, cos there 1 or 2 that don't really work that well, such as texZK's code and one of the codes that Ripper displayed. TexZK's code caused all the menus to appear on one page and it used up bytes, one of Ripper's codes caused the game to play incorrectly with odd screen glitches.

Sorry to tell you this...
...you're goin to have to restart if you didn't make backups.







With all these changes I managed to free 17344 bytes, and that is even with a few source code tutorials inserted (Floor & ceiling textures, high res images, 5th difficulty level, Outdoor Atmosphere, Directional Sprites)
User avatar
Chris
DieHard Wolfer
DieHard Wolfer
Posts: 2279
Joined: Wed Mar 12, 2003 1:03 am
Location: Canada

my 3 favorite arrays must come together on valentines

Post by Chris »

Heh. Not sure if you'll find this interesting, but I managed to get 8192 more near bytes by combining spotvis with tilemap, and by compressing actorat into a byte.

http://www.canadianphilatelics.com/choksta/22612.zip

Seems to play the same as the original (83.exe) on my computer, how about on yours? The 22612.exe one has Ripper's "remove the scalers" enabled, while 20793.exe uses the original scaler (seems to have a better framerate). If you downsize the screen in debug mode, it'll show your near memory. I'm pretty tired right now, but maybe I'll optimize the tilemap/actorat stuff a little more later (I tried to put all three into 4096 bytes at first, almost worked - lol). Pretty fun arrays to experiment with. :D
User avatar
wolf3dbreaker
I am Death Incarnate
I am Death Incarnate
Posts: 196
Joined: Tue Jun 10, 2003 5:08 am
Location: Philippines

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by wolf3dbreaker »

Haasboy wrote:Did you test your engine after each change, cos there 1 or 2 that don't really work that well, such as texZK's code and one of the codes that Ripper displayed. TexZK's code caused all the menus to appear on one page and it used up bytes, one of Ripper's codes caused the game to play incorrectly with odd screen glitches.

Sorry to tell you this...
...you're goin to have to restart if you didn't make backups.







With all these changes I managed to free 17344 bytes, and that is even with a few source code tutorials inserted (Floor & ceiling textures, high res images, 5th difficulty level, Outdoor Atmosphere, Directional Sprites)

Gee... This only seems to happen if I have the digitized sounds on.
Gone from the community for a while. Will be back on July
User avatar
Chris
DieHard Wolfer
DieHard Wolfer
Posts: 2279
Joined: Wed Mar 12, 2003 1:03 am
Location: Canada

Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Chris »

Ripper wrote:- Remove ylookup in ID_VL.C and replace its usage by calculations. Result: aprox. 400 bytes
- Same for farmapylookup. Result: aprox. 128 bytes
Cool idea Ripper. I just noticed this today too. It's funny, I was always just using y*MAPSIZE+x when displaying maps on the screen (as I like to watch everything in the background while playing); then I looked at how ID did it for mapsegs, to see if they used the same idea, which is when I realized the purpose of the farmapylookup table, and how simple it would be to remove - lol.

I'm curious, for the ylookup tables, I just replaced them all with linewidth*y (y being whatever variable was inside ylookup), but I'm not too sure of the best way to multiply in ASM (there is MUL, which ID never seems to use; and there is "*", which doesn't seem to work unless you carry some variables into immediate locations). Here's how my VL_LatchToScreen() starts off right now:
void VL_LatchToScreen (unsigned source, int width, int height, int x, int y)
{
	VGAWRITEMODE(1);
	VGAMAPMASK(15);
	x = bufferofs+linewidth*y+(x>>2);

asm	mov	di,[x]
asm	mov	si,[source]
asm	mov	ax,[width]
asm	mov	bx,[linewidth]

asm	sub	bx,ax
Just curious if there was a more practical way to do this (or if converting it to ASM really matters on 21st century computers). I had this weird idea to store it's SHR 4 and 6 results into different locations; then add them together (which I think would make it multiply y by 80 - linewidth), but I'm not sure if that would make things any faster. I wanted to try something similar for the blockstart tables (which would work out to something like (y*4 + (y/UPDATEWIDE)*1280), but I'll keep analyzing how ID does this multiply/divide stuff efficiently and play around with ideas.

Those horizwall and vertwall tables that are loaded in SetupWalls() were also pretty easy to move into calculations (saving 256 bytes for each 64 walls). I'm sure there are others like that lying around too. Thanks for the ylookup idea. :)
User avatar
Codetech84
Code Master
Code Master
Posts: 1282
Joined: Wed Mar 12, 2003 4:38 pm
Location: Rauma - Finland

Re: [Info] Freeing Up Memory - A Must Read!

Post by Codetech84 »

Ok Chris, since you hated the fact that CFDB program had that constant default directory, here's your chance to change it..

CFDB 2.0 vga (Open Source Project)

http://www.freewebs.com/codetech84/CFDB20vga_OS.zip
User avatar
Reactor
DieHard SS
DieHard SS
Posts: 328
Joined: Thu Mar 17, 2005 12:40 pm
Location: Hungary

Re: [Info] Freeing Up Memory - A Must Read!

Post by Reactor »

Uh-oh,so what is the correct procedure to free up tons of memory for Wolfenstein 3D?
I have 1 GB RAM,even Doom 3 runs smoothly on ultra quality, so Wolfenstein 3D could use plenty of them. I just read I'll need to free up some to avoid the annoying "Abnormal program termination" message. Which file(s) to edit?
INCOMING TRANSMISSION
"Marine! Er....never mind..."
TRANSMISSION ENDS
User avatar
Haasboy
DieHard Officer
DieHard Officer
Posts: 595
Joined: Wed Jul 23, 2003 5:43 pm
Location: South Africa, Johannesburg

Re: [Info] Freeing Up Memory - A Must Read!

Post by Haasboy »

Well if you read the whole entire topic it'll tell you in each reply that everybody has written on what needs to be edited in order to free up memory.

Wolf basically runs off it's own memory (I'm not quite sure what they called it), but if you go over the limit you encounter the "Abnormal termination" error. By opening the WOLF.MAP file compiled results folder at the very end, you'll be able to calculate (using MCS routine) how much space you have left before you encounter that error.
Guest

Re: [Info] Freeing Up Memory - A Must Read!

Post by Guest »

changing maxactors to 101 from 150 will free up 2940 bytes (changing it to 100 frees up a little less for some reason? :| )
maxobjects from 400 to 300 will free up 800 bytes
64 to 40 max doors will free up 288 bytes.
find all those in wl_def.h of course. if you are desparate for memory and are willing to make some sacrifices (how often do you need 150 actors or 400 objects in one level?) a great way to free some up :cheesy: i also screwed with the max walltiles and put them to what my current ammount of walls is but the ammount it freed up (44 bytes goin from 64 to 53 walls) isnt worth the pain to recompile it every time another wall is added (unless of course you do this as a finishing touch)
User avatar
Zombie_Plan
DieHard Wolfer
DieHard Wolfer
Posts: 1880
Joined: Wed Oct 13, 2004 4:37 am
Location: A hole in the wall

Re: [Info] Freeing Up Memory - A Must Read!

Post by Zombie_Plan »

Um, yes. But it limits the maps, leading to some rather simple map designs.
User avatar
Tricob
Moderator
<b>Moderator</b>
Posts: 9040
Joined: Tue Mar 15, 2005 2:43 am
Location: Neo-traditions, Inc.

Re: [Info] Freeing Up Memory - A Must Read!

Post by Tricob »

Re: Removing CO.ASM, WOLFHACK.C & WHACK_A.ASM from Wolf3d.prj

Does anyone have a working link to this tutorial? I tried accessing it from the http://www.areyep.com/Codingtips/abnormal.html URL, and I got an error. :(
User avatar
Haasboy
DieHard Officer
DieHard Officer
Posts: 595
Joined: Wed Jul 23, 2003 5:43 pm
Location: South Africa, Johannesburg

Re: [Info] Freeing Up Memory - A Must Read!

Post by Haasboy »

Tricob wrote:Re: Removing CO.ASM, WOLFHACK.C & WHACK_A.ASM from Wolf3d.prj

Does anyone have a working link to this tutorial? I tried accessing it from the http://www.areyep.com/Codingtips/abnormal.html URL, and I got an error. :(
In BC.EXE look at all the files that are compiled
H_LDIV.ASM
WL_ASM.ASM
WL_MAIN.C.......etc
There are those three files amongst them delete CO.ASM, WOLFHACK.C and WHACK_A.ASM.
User avatar
Zero X. Diamond
DieHard Guard
DieHard Guard
Posts: 268
Joined: Mon Mar 22, 2004 11:31 am
Location: The Planet of the Tiny Hut People

Re: [Info] Freeing Up Memory - A Must Read!

Post by Zero X. Diamond »

So, anybody got a source with all these memory fixes in it for download?
Hooray for vaporware!
User avatar
Chris
DieHard Wolfer
DieHard Wolfer
Posts: 2279
Joined: Wed Mar 12, 2003 1:03 am
Location: Canada

Re: [Info] Freeing Up Memory - A Must Read!

Post by Chris »

Zero X. Diamond wrote:So, anybody got a source with all these memory fixes in it for download?
If this helps, I've been adding just about all the interesting memory/bug fixes I can find to memboost; just for fun.

http://www.canadianphilatelics.com/choksta/memboost.zip

Feel free to use it, and let me know if everything works ok. It should play exactly like the original wolf3d, even with all the fixes listed in the readme. I've been constantly updating it as I find new things to improve in the original source code, with alot of help from the topics/ideas you guys post in this thread and Code Crackers. :)
User avatar
KyleRTCW
DieHard Officer
DieHard Officer
Posts: 511
Joined: Thu Jul 31, 2003 1:11 am
Location: Ohio

Re: [Info] Freeing Up Memory - A Must Read!

Post by KyleRTCW »

Deathshead said that Operation Todpfad takes a lot of memory, when I start up the bar goes to 256, when I start EoD, i get 320 :\ and EoD has tons mrope features then OT. I've tried almost everything to help conserve memory but nothing is working, my game is gonna be a memory hog. He said he couldn't even run it on his computer without a tool like Dosbox or something. If I could get this memory bug out of the way I'd release todpfad. It's basically done. Just a few ends to tie up. I've gotten rid of the funcutions I dont wants such as unwanted cheats, death cam, etc... Does anyone have any tips for why my game is taking up too much memory so I can raise the bar to 320?

If some coder (a one who knows his/her coding stuff) would want to take a look at it, I'd apperciate it. But I doubt anyone would.

Thanks,
Kyle