DieHard Wolfers Forum Index DieHard Wolfers
A Wolfenstein 3d Fan Community


  Hosted by: MCS & Areyep.com - Designed by: BrotherTank

Original Yahoo Forum - Die Hard Archives

AReyeP HomepageAreyep Homepage DieHard Wolfenstein BunkerDieHard Wolfenstein Bunker Log inLog in RegisterRegister Banlist FAQFAQ Search ForumsSearch

  Username:    Password:      Remember me       

[Info] Freeing Up Memory - A Must Read!
Page 3 of 5 Goto page Previous  1, 2, 3, 4, 5  Next
DieHard Wolfers Forum Index -> Code Crackers View Previous TopicRefresh this PageAdd Topic to your Browser FavoritesSearch ForumsPrint this TopicE-mail TopicGoto Page BottomView Next Topic
Post new topicReply to topic
Author Message
Ripper
Code Master - Developer
Code Master - Developer


Joined: 15 Mar 2003
Last Visit: 30 Sep 2008

Topics: 21
Posts: 527
Location: Germany
blank.gif

PostPosted: Sat Jan 29, 2005 6:20 am
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Next PostGoto Bottom of Posts

Great work, Chris Mr Green
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! Shocked

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 Wink
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2255
Location: Ontario
canada.gif

PostPosted: Sat Jan 29, 2005 10:01 am
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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
Ripper
Code Master - Developer
Code Master - Developer


Joined: 15 Mar 2003
Last Visit: 30 Sep 2008

Topics: 21
Posts: 527
Location: Germany
blank.gif

PostPosted: Sat Jan 29, 2005 3:29 pm
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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(...))
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2255
Location: Ontario
canada.gif

PostPosted: Sat Jan 29, 2005 9:03 pm
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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
Ripper
Code Master - Developer
Code Master - Developer


Joined: 15 Mar 2003
Last Visit: 30 Sep 2008

Topics: 21
Posts: 527
Location: Germany
blank.gif

PostPosted: Fri Feb 04, 2005 3:27 pm
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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

Here we go: Mr Green

  • 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 Mr Green
Now I'll start doing what I originally wanted to do with the source *playingaroundonsomethinginteresting* Secret

PS: OK, just as I thought Mr Green
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)
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Fri Feb 04, 2005 5:23 pm
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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. Smile

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/choksta/backup/quitinfo.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. Wink
Haasboy
DieHard Officer
DieHard Officer


Joined: 23 Jul 2003
Last Visit: 14 Feb 2018

Topics: 58
Posts: 581
Location: South Africa, Johannesburg
southafrica.gif

PostPosted: Fri Feb 04, 2005 10:02 pm
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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.

_________________
Haasboy Engine - Currently under construction (To be used with future mods - F.A.D.E.D. - Mansion X - Rising Evil Series)
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Sat Feb 05, 2005 7:02 am
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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.
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Mon Feb 07, 2005 10:08 pm
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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:

::: CODE :::
#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:

::: CODE :::
   leftchannel  =  lefttable[x][y + ATABLEMAX];
   rightchannel = righttable[x][y + ATABLEMAX];

And replace it with this:

::: CODE :::
   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. Smile


Last edited by Chris on Mon Jun 20, 2016 11:50 am; edited 2 times in total
Ripper
Code Master - Developer
Code Master - Developer


Joined: 15 Mar 2003
Last Visit: 30 Sep 2008

Topics: 21
Posts: 527
Location: Germany
blank.gif

PostPosted: Tue Feb 08, 2005 10:04 am
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Good work! I always thought this to be quite oversized, but was too stupid too see how to reduce it Mr Green
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 Mr Green)
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2255
Location: Ontario
canada.gif

PostPosted: Tue Feb 08, 2005 11:25 am
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

@Ripper and Chris:

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

Core:
  
9936
Far:
  
287008
Total: 296944

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

Core:
  
11680
Far:
  
287024
Total: 298704

And with Ripper's Cloudy Sky Enabled:

Core:
  
11600
Far:
  
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
Haasboy
DieHard Officer
DieHard Officer


Joined: 23 Jul 2003
Last Visit: 14 Feb 2018

Topics: 58
Posts: 581
Location: South Africa, Johannesburg
southafrica.gif

PostPosted: Wed Feb 09, 2005 9:22 am
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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:
::: CODE :::
   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.
::: CODE :::
MORE INFO ABOVE
......
 3823:B276       _bordercolor
 3823:B278       _ylookup
 3823:B408       _linewidth
 3823:B40A       _pelpan
 3823:B40C       _bufferheight
 3823:B40E       _bufferwidth

_________________
Haasboy Engine - Currently under construction (To be used with future mods - F.A.D.E.D. - Mansion X - Rising Evil Series)
BrotherTank
Forum Administrator
<B>Forum Administrator</B>


Joined: 01 Mar 2003
Last Visit: 13 Sep 2017

Topics: 153
Posts: 2255
Location: Ontario
canada.gif

PostPosted: Wed Feb 09, 2005 9:55 am
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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:
::: CODE :::
   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.
::: CODE :::
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
Haasboy
DieHard Officer
DieHard Officer


Joined: 23 Jul 2003
Last Visit: 14 Feb 2018

Topics: 58
Posts: 581
Location: South Africa, Johannesburg
southafrica.gif

PostPosted: Wed Feb 09, 2005 12:55 pm
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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 Mr Green

_________________
Haasboy Engine - Currently under construction (To be used with future mods - F.A.D.E.D. - Mansion X - Rising Evil Series)
TexZK
DieHard SS
DieHard SS


Joined: 07 Feb 2004
Last Visit: 17 Oct 2016

Topics: 19
Posts: 370
Location: Northern Italy
italy.gif

PostPosted: Thu Feb 10, 2005 3:04 am
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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

Good work, boys!!!

Another change: in "WL_MENU.H":

::: CODE :::
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;".
wolf3dbreaker
I am Death Incarnate
I am Death Incarnate


Joined: 09 Jun 2003
Last Visit: 29 Sep 2009

Topics: 31
Posts: 196
Location: Philippines
philippines.gif

PostPosted: Fri Feb 18, 2005 5:28 am
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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
Haasboy
DieHard Officer
DieHard Officer


Joined: 23 Jul 2003
Last Visit: 14 Feb 2018

Topics: 58
Posts: 581
Location: South Africa, Johannesburg
southafrica.gif

PostPosted: Fri Feb 18, 2005 12:21 pm
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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)

_________________
Haasboy Engine - Currently under construction (To be used with future mods - F.A.D.E.D. - Mansion X - Rising Evil Series)
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Fri Feb 18, 2005 3:01 pm
   Subject: my 3 favorite arrays must come together on valentines
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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. Very Happy
wolf3dbreaker
I am Death Incarnate
I am Death Incarnate


Joined: 09 Jun 2003
Last Visit: 29 Sep 2009

Topics: 31
Posts: 196
Location: Philippines
philippines.gif

PostPosted: Fri Feb 18, 2005 3:41 pm
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Fri Feb 25, 2005 5:00 am
   Subject: Re: [Info] Saving 256 bytes of the data segment in ID_SD_A.A
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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:

::: CODE :::
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. Smile
Codetech84
Code Master
Code Master


Joined: 12 Mar 2003
Last Visit: 01 Apr 2018

Topics: 22
Posts: 1283
Location: Rauma - Finland
finland.gif

PostPosted: Tue Mar 22, 2005 3:13 am
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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

_________________
Click here to visit KFH Games website!
*UPDATED* Spear of Destiny Reloaded
KFH Games on Facebook
Reactor
DieHard SS
DieHard SS


Joined: 17 Mar 2005
Last Visit: 24 Jan 2013

Topics: 27
Posts: 328
Location: Hungary
hungary.gif

PostPosted: Mon Apr 25, 2005 2:09 am
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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
Haasboy
DieHard Officer
DieHard Officer


Joined: 23 Jul 2003
Last Visit: 14 Feb 2018

Topics: 58
Posts: 581
Location: South Africa, Johannesburg
southafrica.gif

PostPosted: Wed Apr 27, 2005 10:21 am
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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.

_________________
Haasboy Engine - Currently under construction (To be used with future mods - F.A.D.E.D. - Mansion X - Rising Evil Series)
Guest




Last Visit:





PostPosted: Wed May 11, 2005 9:20 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

changing maxactors to 101 from 150 will free up 2940 bytes (changing it to 100 frees up a little less for some reason? Neutral )
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 Grin 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)
Zombie_Plan
DieHard Wolfer
DieHard Wolfer


Joined: 12 Oct 2004
Last Visit: 07 Jun 2016

Topics: 101
Posts: 1614
Location: A hole in the wall
australia.gif

PostPosted: Wed May 11, 2005 9:31 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

Um, yes. But it limits the maps, leading to some rather simple map designs.
Tricob
Moderator
<B>Moderator</B>


Joined: 14 Mar 2005
Last Visit: 10:25 ago.

Topics: 163
Posts: 8120
Location: Neo-traditions, Inc.
usa.gif

PostPosted: Sat May 21, 2005 7:17 pm
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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. Sad
Haasboy
DieHard Officer
DieHard Officer


Joined: 23 Jul 2003
Last Visit: 14 Feb 2018

Topics: 58
Posts: 581
Location: South Africa, Johannesburg
southafrica.gif

PostPosted: Sun May 22, 2005 1:52 am
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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. Sad


In BC.EXE look at all the files that are compiled

::: CODE :::
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.

_________________
Haasboy Engine - Currently under construction (To be used with future mods - F.A.D.E.D. - Mansion X - Rising Evil Series)
Zero X. Diamond
DieHard Guard
DieHard Guard


Joined: 22 Mar 2004
Last Visit: 13 Jul 2012

Topics: 25
Posts: 265
Location: The Planet of the Tiny Hut People
ussr.gif

PostPosted: Fri Jun 24, 2005 3:09 am
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

So, anybody got a source with all these memory fixes in it for download?

_________________
Hooray for vaporware!
Chris
DieHard Wolfer
DieHard Wolfer


Joined: 11 Mar 2003
Last Visit: 16 Apr 2018

Topics: 55
Posts: 2128
Location: Canada
blank.gif

PostPosted: Fri Jun 24, 2005 6:47 am
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Next PostGoto Bottom of Posts

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. Smile
KyleRTCW
DieHard Officer
DieHard Officer


Joined: 30 Jul 2003
Last Visit: 11 Apr 2018

Topics: 45
Posts: 510
Location: Ohio
usa.gif

PostPosted: Sat Jul 02, 2005 6:14 am
   Subject: Re: [Info] Freeing Up Memory - A Must Read!
   [ IP : Logged ]
Reply with quote
Goto Top of PostsGoto Previous PostGoto Bottom of Posts

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

_________________
Steam: http://steamcommunity.com/id/stormx312
Display posts from previous:   
Post new topicReply to topic Time synchronized with the forum server time
DieHard Wolfers Forum Index -> Code Crackers View Previous TopicRefresh this PageAdd Topic to your Browser FavoritesSearch ForumsPrint this TopicE-mail TopicGoto Page TopView Next Topic
Page 3 of 5 Goto page Previous  1, 2, 3, 4, 5  Next
Jump to:  

Related topics
 Topics   Replies   Views   Last Post 
No new posts Sticky: [Info] Help for newbie coders! C++ Tutorial
Author: Dugtrio17
20 8521 Sun Jan 10, 2010 12:26 pm
Fragstein3D View latest post
No new posts [Info] Tricks - Dogs that shoot - Modifying Behaviour
Author: Guest
19 288 Sat Mar 20, 2004 7:31 am
Dugtrio17 View latest post
No new posts [Info] Alarm Sounding in game?? WSJ...??
Author: Guest
7 309 Tue Jun 17, 2003 10:04 pm
Reivax44 View latest post
No new posts [Info] Silent Gun? - Adding a Silencer
Author: Guest
4 194 Fri Apr 18, 2003 8:34 am
BrotherTank View latest post
No new posts [Info] Adding Locked Doors
Author: Guest
3 243 Thu Apr 17, 2003 6:30 am
Ripper View latest post
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
   You cannot delete your posts in this forum
You cannot vote in polls in this forum


Copyright ©2003-2008 DieHard Wolfers
A Modified subBunker Theme by BrotherTank
Powered by phpBB © 2001, 2005 phpBB Group