[Info] Freeing Up Memory - A Must Read!

Wolf3d Code & Tutorial Development Area

Moderators: Andy_Nonymous, Adam Biser, BrotherTank

User avatar
Hair Machine
DieHard SS
DieHard SS
Posts: 427
Joined: Mon Nov 24, 2003 8:15 pm
Location: editing my profile

Re: Data Bytes! Darn them!

Post by Hair Machine »

Oh yeah, I use it all the time. Very useful indeed, I have to say. :2cool:
Rar rar fiddle di dee
User avatar
Codetech84
Code Master
Code Master
Posts: 1282
Joined: Wed Mar 12, 2003 4:38 pm
Location: Rauma - Finland

Re: Data Bytes! Darn them!

Post by Codetech84 »

I'm flattered... :shock:

You must be the first one to ever thank me. Have you downloaded the metallic skin?
User avatar
Chris
DieHard Wolfer
DieHard Wolfer
Posts: 2279
Joined: Wed Mar 12, 2003 1:03 am
Location: Canada

Re: Data Bytes! Darn them!

Post by Chris »

Yes, great program indeed. :roll:

Image
If anyone actually got this to work (I've tried many different folders, source codes, capitalizations, etc.), could you post the text from your log file in this thread? I'd like to see if this program does anything useful that I wouldn't be able to easily figure out on my own. So far, CFDB seems like more of a pain in the rear end than anything - lol.

Link: http://www.btinternet.com/~belowe (Extras)

EDIT -

Nevermind, I finally got CFDB to work. That question "Enter your project output dir" is a bug, because it doesn't work unless you don't type anything. Weird, isn't it? The only way to pass the question is to copy your MAP files into the stupid default directory every time (which you have to make), which is called C:\PROJECT\SOURCE\OBJ; than press [Enter] on the question. Even if that problem didn't exist... I still think there should be an INI file or something so people can set their own defaults without having to type in all that info every time. :P

Beyond all that, the program is ok - I guess. I like some things about it, like how you added some colours, a sound, and the parsing technique. The actual idea and calculations are nothing new and/or special though, and I wouldn't be surprised if you just ripped them from MCS's page without giving credit. By mentioning the PRJ file, I assumed that you were opening this file... perhaps to look for the right directory for the MAP file inside it - but that wasn't the case. Your system for judging "what is Normal" is questionable. For instance, if your project is almost done... being Low is irrelevant (as it's hard coded); and if you wanted to do ALOT of changes (say, making 128x128 maps and adding a sky feature), 1000 bytes is not "Good" (unless you want to throw that stuff into weaker forms of memory). The standard/minimal free bytes someone is looking for can depend on many things, right?

Alright, that's all I wanted to say. Have a nice day... while I have a nice sleep! :mrgreen:
User avatar
Hair Machine
DieHard SS
DieHard SS
Posts: 427
Joined: Mon Nov 24, 2003 8:15 pm
Location: editing my profile

Re: Data Bytes! Darn them!

Post by Hair Machine »

I think (although I'm not sure, after all it is Codetech's program) that the problem with the output dir input is due to QBasic's crappy string handling 'INPUT x$' routine. Which means you have to have the string perfectly - capital letters in all the right places, etc - to get it to recognize what you're saying. You also may have to put a slash at the end of the input, but I'm not sure about that either. Basically, this is what I write: C:\BORLANDC\BlitzCode\OBJ\ ... Notice the capitals and random non-capitals. And that works absolutely fine.

And no, I had no idea there was a skin for it! I'm intrigued now... I must download
Rar rar fiddle di dee
User avatar
Chris
DieHard Wolfer
DieHard Wolfer
Posts: 2279
Joined: Wed Mar 12, 2003 1:03 am
Location: Canada

Re: Data Bytes! Darn them!

Post by Chris »

Ah yes, you're right Hair Machine. I NEEDED to type the slash at the end, which is ironic, because the default directory in the exe AND the example Codetech84 provided the text file both DON'T have a slash at the end... and there wasn't anything mentioned about this in the readme. As for using the correct capitalization, I guess angelfire isn't letting people look at images anymore... but as you can tell from this picture (uploaded to a different server), I typed that stuff perfectly:

http://www.canadianphilatelics.com/chok ... s/cfdb.gif

I still think this program is just a giant rip off of MCS's idea though (which I still think was alot eaiser), even the default directories are exactly the same! Here's the link to the original page, you can judge for yourself. Remember Codetech, no stealing! :P
User avatar
WSJ
DieHard Officer
DieHard Officer
Posts: 534
Joined: Sun Apr 18, 2004 1:16 am
Location: Development Hell

Re: Data Bytes! Darn them!

Post by WSJ »

Hehe... Yeah, I just like to stick with the method MCS describes. I don't really see the need for a "special program" to do it.
User avatar
Codetech84
Code Master
Code Master
Posts: 1282
Joined: Wed Mar 12, 2003 4:38 pm
Location: Rauma - Finland

Re: Data Bytes! Darn them!

Post by Codetech84 »

The VGA version is easier to use, also there's error trapping for loading of files.
Chris wrote:I still think this program is just a giant rip off of MCS's idea though (which I still think was alot eaiser), even the default directories are exactly the same! Here's the link to the original page, you can judge for yourself. Remember Codetech, no stealing! :P
I'm sorry for not giving MCS the credit, must've slipped my mind. And even though the defaults are the same, I only "ripped" the calculation technique from MCS. The defaults came there long after I finished the calculation stuff

I do appreciate your opinion...

Edit:

@chris: How'd you get to see my source code?
I've been thinking for a open source release...

I've been thinking of making an extended windows version. I would like to know what would you like to see in the program. Also I'd like to recieve ideas for the layout of the program. If you can think of anything let me know. I don't want you hear you dissing this project before it's even started...
Guest

Re: Data Bytes! Darn them!

Post by Guest »

It has remembered me of one thing. Sometimes the Abnormal Program Termination appears with the game KB in 479,483 or 490. Anyone know which is the problem? (I've just used this topic to don't create another one of data bytes)
User avatar
Codetech84
Code Master
Code Master
Posts: 1282
Joined: Wed Mar 12, 2003 4:38 pm
Location: Rauma - Finland

Re: Data Bytes! Darn them!

Post by Codetech84 »

Simply put...

Data bytes != Functions
User avatar
Adam Biser
Utility Developer
Utility Developer
Posts: 2415
Joined: Fri Jun 06, 2003 5:53 pm
Location: USA

Freeing a few more data bytes...

Post by Adam Biser »

This will probably be more work than what it's worth, but here's something that can free up a few more data bytes...

If WL_DEF.H change the appropriate section to:
typedef enum {
	nothing,
	playerobj,
	inertobj,
	guardobj,
	officerobj,
	ssobj,
	dogobj,
#ifndef SPEAR
	bossobj,
	schabbobj,
	fakeobj,
	mechahitlerobj,
#endif
	mutantobj,
#ifndef SPEAR
	needleobj,
#endif
	fireobj,
	bjobj,
#ifndef SPEAR
	ghostobj,
	realhitlerobj,
	gretelobj,
	giftobj,
	fatobj,
	rocketobj
#endif
#ifdef SPEAR
	rocketobj,
	spectreobj,
	angelobj,
	transobj,
	uberobj,
	willobj,
	deathobj,
	hrocketobj,
	sparkobj
#endif
} classtype;
typedef enum {
	dressing,
	block,
	bo_gibs,
	bo_alpo,
	bo_firstaid,
	bo_key1,
	bo_key2,
	bo_key3,
	bo_key4,
	bo_cross,
	bo_chalice,
	bo_bible,
	bo_crown,
	bo_clip,
	bo_clip2,
	bo_machinegun,
	bo_chaingun,
	bo_food,
	bo_fullheal
#ifdef SPEAR
	,
	bo_25clip,
	bo_spear
#endif
} stat_t;
#ifdef SPEAR
	#define NUMENEMIES		11
#else
	#define NUMENEMIES		16
#endif
typedef enum {
	en_guard,
	en_officer,
	en_ss,
	en_dog,
#ifndef SPEAR
	en_boss,
	en_schabbs,
	en_fake,
	en_hitler,
#endif
	en_mutant,
#ifndef SPEAR
	en_blinky,
	en_clyde,
	en_pinky,
	en_inky,
	en_gretel,
	en_gift,
	en_fat
#else
	en_spectre,
	en_angel,
	en_trans,
	en_uber,
	en_will,
	en_death
#endif
} enemy_t;
extern	statetype s_grddie1;
extern	statetype s_dogdie1;
extern	statetype s_ofcdie1;
extern	statetype s_mutdie1;
extern	statetype s_ssdie1;

#ifndef SPEAR
extern	statetype s_bossdie1;
extern	statetype s_schabbdie1;
extern	statetype s_fakedie1;
extern	statetype s_mechadie1;
extern	statetype s_hitlerdie1;
extern	statetype s_greteldie1;
extern	statetype s_giftdie1;
extern	statetype s_fatdie1;
#else
extern	statetype s_spectredie1;
extern	statetype s_angeldie1;
extern	statetype s_transdie0;
extern	statetype s_uberdie0;
extern	statetype s_willdie1;
extern	statetype s_deathdie1;
#endif

extern	statetype s_grdchase1;
extern	statetype s_dogchase1;
extern	statetype s_ofcchase1;
extern	statetype s_sschase1;
extern	statetype s_mutchase1;

#ifndef SPEAR
extern	statetype s_bosschase1;
extern	statetype s_schabbchase1;
extern	statetype s_fakechase1;
extern	statetype s_mechachase1;
extern	statetype s_gretelchase1;
extern	statetype s_giftchase1;
extern	statetype s_fatchase1;
#else
extern	statetype s_spectrechase1;
extern	statetype s_angelchase1;
extern	statetype s_transchase1;
extern	statetype s_uberchase1;
extern	statetype s_willchase1;
extern	statetype s_deathchase1;
#endif

#ifndef SPEAR
extern	statetype s_blinkychase1;
extern	statetype s_hitlerchase1;
#endif

extern	statetype s_grdpain;
extern	statetype s_grdpain1;
extern	statetype s_ofcpain;
extern	statetype s_ofcpain1;
extern	statetype s_sspain;
extern	statetype s_sspain1;
extern	statetype s_mutpain;
extern	statetype s_mutpain1;

extern	statetype s_deathcam;

#ifndef SPEAR
extern	statetype s_schabbdeathcam2;
extern	statetype s_hitlerdeathcam2;
extern	statetype s_giftdeathcam2;
extern	statetype s_fatdeathcam2;
#endif

void SpawnStand (enemy_t which, int tilex, int tiley, int dir);
void SpawnPatrol (enemy_t which, int tilex, int tiley, int dir);
void KillActor (objtype *ob);

void	US_ControlPanel(byte);

void SpawnDeadGuard (int tilex, int tiley);
#ifndef SPEAR
void SpawnBoss (int tilex, int tiley);
void SpawnGretel (int tilex, int tiley);
#else
void SpawnTrans (int tilex, int tiley);
void SpawnUber (int tilex, int tiley);
void SpawnWill (int tilex, int tiley);
void SpawnDeath (int tilex, int tiley);
void SpawnAngel (int tilex, int tiley);
void SpawnSpectre (int tilex, int tiley);
#endif
#ifndef SPEAR
void SpawnGhosts (int which, int tilex, int tiley);
void SpawnSchabbs (int tilex, int tiley);
void SpawnGift (int tilex, int tiley);
void SpawnFat (int tilex, int tiley);
void SpawnFakeHitler (int tilex, int tiley);
void SpawnHitler (int tilex, int tiley);
#endif
In WL_DRAW.C... CalcRotate
#ifdef SPEAR
	if (ob->obclass == rocketobj || ob->obclass == hrocketobj)
#else
	if (ob->obclass == rocketobj)
#endif
WL_STATE.C... MoveObj
#ifdef SPEAR
		if (ob->obclass == spectreobj)
#else
		if (ob->obclass == ghostobj)
#endif
WL_STATE.C... SightPlayer
#ifndef SPEAR
		case bossobj:
		case schabbobj:
		case fakeobj:
		case mechahitlerobj:
		case realhitlerobj:
		case gretelobj:
		case giftobj:
		case fatobj:
#else
		case spectreobj:
		case angelobj:
		case transobj:
		case uberobj:
		case willobj:
		case deathobj:
#endif
I *think* that's everywhere the objects are referenced. I have only tried this from the Wolfenstein side, so I'm not sure that's everything you need for SOD, but it's a start for those of you who may need to free up some data bytes (not very many, I'm afraid).

If you want, you can also get rid of "bo_key3" and "bo_key4" from WL_DEF.H, WL_ACT1.C, and WL_AGENT.C.
Unless, of course, you're using more than 2 keys...
EDIT: Forgot some changes... it should compile now.
WL_AGENT.C - GetBonus:
#ifdef SPEAR
	case	bo_spear:
		spearflag = true;
		spearx = player->x;
		speary = player->y;
		spearangle = player->angle;
		playstate = ex_completed;
#endif
WL_ACT1.C - SpawnStatic:
	case	bo_firstaid:
	case	bo_key1:
	case	bo_key2:
//	case	bo_key3:
//	case	bo_key4:
	case	bo_clip:
	case	bo_machinegun:
	case	bo_chaingun:
	case	bo_food:
	case	bo_alpo:
	case	bo_gibs:
#ifdef SPEAR
	case	bo_25clip:
	case	bo_spear:
#endif
WL_ACT2.C:
int	starthitpoints[4][NUMENEMIES] =
	 //
	 // BABY MODE
	 //
	 {
	 {25,	// guards
	  50,	// officer
	  100,	// SS
	  1,	// dogs
#ifndef SPEAR
	  850,	// Hans
	  850,	// Schabbs
	  200,	// fake hitler
	  800,	// mecha hitler
#endif
	  45,	// mutants
#ifndef SPEAR
	  25,	// ghosts
	  25,	// ghosts
	  25,	// ghosts
	  25,	// ghosts

	  850,	// Gretel
	  850,	// Gift
	  850	// Fat
#else
	  5,	// en_spectre,
	  1450,	// en_angel,
	  850,	// en_trans,
	  1050,	// en_uber,
	  950,	// en_will,
	  1250	// en_death
#endif
	  },
	 //
	 // DON'T HURT ME MODE
	 //
	 {25,	// guards
	  50,	// officer
	  100,	// SS
	  1,	// dogs
#ifndef SPEAR
	  950,	// Hans
	  950,	// Schabbs
	  300,	// fake hitler
	  950,	// mecha hitler
#endif
	  55,	// mutants
#ifndef SPEAR
	  25,	// ghosts
	  25,	// ghosts
	  25,	// ghosts
	  25,	// ghosts

	  950,	// Gretel
	  950,	// Gift
	  950	// Fat
#else
	  10,	// en_spectre,
	  1550,	// en_angel,
	  950,	// en_trans,
	  1150,	// en_uber,
	  1050,	// en_will,
	  1350	// en_death
#endif
	  },
	 //
	 // BRING 'EM ON MODE
	 //
	 {25,	// guards
	  50,	// officer
	  100,	// SS
	  1,	// dogs

#ifndef SPEAR
	  1050,	// Hans
	  1550,	// Schabbs
	  400,	// fake hitler
	  1050,	// mecha hitler
#endif
	  55,	// mutants
#ifndef SPEAR
	  25,	// ghosts
	  25,	// ghosts
	  25,	// ghosts
	  25,	// ghosts

	  1050,	// Gretel
	  1050,	// Gift
	  1050	// Fat
#else
	  15,	// en_spectre,
	  1650,	// en_angel,
	  1050,	// en_trans,
	  1250,	// en_uber,
	  1150,	// en_will,
	  1450	// en_death
#endif
	  },
	 //
	 // DEATH INCARNATE MODE
	 //
	 {25,	// guards
	  50,	// officer
	  100,	// SS
	  1,	// dogs

#ifndef SPEAR
	  1200,	// Hans
	  2400,	// Schabbs
	  500,	// fake hitler
	  1200,	// mecha hitler
#endif
	  65,	// mutants
#ifndef SPEAR
	  25,	// ghosts
	  25,	// ghosts
	  25,	// ghosts
	  25,	// ghosts

	  1200,	// Gretel
	  1200,	// Gift
	  1200	// Fat
#else
	  25,	// en_spectre,
	  2000,	// en_angel,
	  1200,	// en_trans,
	  1400,	// en_uber,
	  1300,	// en_will,
	  1600	// en_death
#endif
	  }}
	  ;
WL_ACT2.C - T_Projectile:
			case rocketobj:
#ifdef SPEAR
			case hrocketobj:
			case sparkobj:
#endif
				damage = (US_RndT() >>3) + 30;
				break;
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 More Memory

Post by Haasboy »

Another way to gain memory is to use the Japanese code for the menu, it actually frees up about 300 bytes
User avatar
Blade Nightflame
Bring 'em On
Bring 'em On
Posts: 117
Joined: Thu Dec 23, 2004 7:33 pm

Re: [Info] Freeing Up More Memory

Post by Blade Nightflame »

Always, or usually the Left and Right (not middle) memory bars are at max. Only the middle one is at min.
'Halten Sie!'
User avatar
Ripper
Code Master - Developer
Code Master - Developer
Posts: 527
Joined: Sat Mar 15, 2003 7:39 pm
Location: Germany

[Info] Saving 256 bytes of the data segment in ID_SD_A.ASM

Post by Ripper »

Here's an easy little tut to get 256 more bytes for more reasonable stuff:

Open up ID_SD_A.ASM and search for "pcdtab" at the begining of the file.
There you'll find a large table containing very few information, but using much memory.
Delete this whole table (everything from "pcdtab" until (and including) the last db line before the ";======..." line).

Then go to the SDL_toExtremeAsmService procedure and change this code:
	mov	bl,[es:di]					; Get the byte
	inc	[WORD PTR pcSound]			; Increment pointer

	and	bl,11100000b				; Nuke some of the precision (DEBUG - do this in the table)

	xor	bh,bh
	mov	ah,[pcdtab+bx]				; Translate the byte

	in	al,pcSpeaker
	and	al,11111100b
	or	al,ah
	out	pcSpeaker,al
to this one:
	mov	bl,[es:di]					; Get the byte
	inc	[WORD PTR pcSound]			; Increment pointer

	shr	bl,6
	and	bl,2

	in	al,pcSpeaker
	and	al,11111100b
	or	al,bl
	out	pcSpeaker,al
(Although this pcdtab table doesn't appear directly in the MAP file, you'll see a difference of 256 bytes between _gamepal and _audioname)

Hope that helps ;)

Greets
Ripper
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] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Zombie_Plan »

thankz Ripper.

I've been using different methods to try and free space (when BrotherTank said he still had 5000 bytes free, I wanted to get similar), and have so far freed up approx 3660 bytes. This should help.
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 »

Deathshead wrote:I've been using different methods to try and free space (when BrotherTank said he still had 5000 bytes free, I wanted to get similar), and have so far freed up approx 3660 bytes. This should help.


There's another way to free up space and that is by converting the Japanese code into the source code. By doing this I managed to free up 7256 bytes.
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 »

How can you save memory by altering the Japanese support, when it's not even included into Wolfenstein 3D if you don't explicitly define WOLF_JP or something like that? Could you tell me which file you altered? Perhaps I missed something?? :think:
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 »

Ripper wrote:How can you save memory by altering the Japanese support, when it's not even included into Wolfenstein 3D if you don't explicitly define WOLF_JP or something like that? Could you tell me which file you altered? Perhaps I missed something?? :think:
In the WL_INTER and WL_MAIN file are a whole lot of ifdef JAPAN definitions by converting those you'll be able to free up some bytes. The Japanese code uses mostly images instead of lines of coding.
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 »

You do know, what "#ifdef JAPAN" means?
It means, that the compiler while COMPLETELY ignore everything from this point up to the corresponding "#endif" except you wrote "#define JAPAN" somewhere above (or in any "#include"d file).
So if you just removed those ifdef JAPAN blocks, you only saved some harddisk space because of a smaller source code, but the EXE won't change in any way.

Where did you get that value of "7256 bytes" from? I mean, how did you calculate it?
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 »

Yes I know that but if change the #ifdef to #ifndef it'll use that code. But it takes a lot more work that just changing that code, such as creating all the images (The japanese code uses only images for the menu - which consists of Intermission screens, Confirmation pics (ending a game, quit, etc), Menu screens and various other stuff.

I got the 7256 by using MCS's way at calculating the space.

EDIT: Using the Japanese alternative coding was not the only thing I used to free up space. The other ways were the following:
Used MCS id files
Removed CO.ASM, WOLFHACK.C & WHACK_A.ASM
Used Ripper's No scalers tutorial
Removed the Jukebox feature
Removed the whole entire deathcam
Removed the debugmode
Remove the temp3 code found in WL_DEF
I think that's all...
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 »

Ahhhh!! NOW I understand you!! Not bad! :mrgreen:
So instead of strings you use images as in the Japanese version of Wolf!
OK, great idea, but really sounds like it was hard work...

Hmmm, I wonder how much memory only comes from creating an English version of the Japanese stuff...
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 »

Before using the Japanese code I managed to free about 5000 bytes after using the Japanese code and the code you recently released the free space is now 7504 bytes.

Using the Japanese code is very tricky though so I would recommend a N00b in not doing it as it took me about 2 weeks to get it work correctly. But even the weirdest thing is that even after using the Japanese code and converting it back to the orginal I still had all that free space and it still works 100%.
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 »

Works great here Ripper. Seems to take away the 256 from _ssPort for me. :)
 3767:34F8 idle  _EMMDriverName
 3767:396E idle  _ssPort
 3767:3CE0       _USL_MeasureString
 3767:3CE4 idle  _USL_DrawString
 3766:34F8 idle  _EMMDriverName
 3766:396E idle  _ssPort
 3766:3BE0       _USL_MeasureString
 3766:3BE4 idle  _USL_DrawString
It'd be cool to have a guide for all the ways to save near memory without affecting the game. Dugtrio17 did something like this in the Newsletter, but I'm sure it could be expanded alot further.

For example, if you want to easily save another 604 bytes, change these two lines in WL_DEF.H (since speed only goes up to around 11000, and tilex/y should only go up to 64 anyways):
//--------------------
//
// thinking actor structure
//
//--------------------

typedef struct objstruct
{
	activetype	active;
	int			ticcount;
	classtype	obclass;
	statetype	*state;

	byte		flags;				//	FL_SHOOTABLE, etc

	long		distance;			// if negative, wait for that door to open
	dirtype		dir;

	fixed 		x,y;
	byte		tilex,tiley;
	byte		areanumber;

	int	 		viewx;
	unsigned	viewheight;
	fixed		transx,transy;		// in global coord

	int 		angle;
	int			hitpoints;
	int		speed;

	int			temp1,temp2;
	struct		objstruct	*next,*prev;
} objtype;
You can take this alot further, as alot of these variables are only used for the player (which is only around 1/152 of the entire near data for it)... and many can be condensed with a fair amount of accuracy (like speed and hitpoints into a byte), but would require some extra tweaking. Like this (using WL_ACT2.C and WL_STATE.C):
#ifndef SPEAR
byte	starthitpoints[4][NUMENEMIES-6] =
#else
byte	starthitpoints[4][NUMENEMIES-3] =
#endif
	 //
	 // BABY MODE
	 //
	 {
	 {2,	// guards
	  4,	// officer
	  8,	// SS
	  1,	// dogs
	  68,	// Hans
	  68,	// Schabbs
	  16,	// fake hitler
	  64,	// mecha hitler
	  4,	// mutants
	  2,	// ghosts

etc........
----------------------------------------------------------------

//
// do double damage if shooting a non attack mode actor
//
	if ( !(ob->flags & FL_ATTACKMODE) )
		damage <<= 1;

	ob->hitpoints -= (damage*2/25);

	if (ob->hitpoints<=0 || ob->hitpoints>235)
		KillActor (ob);
It's fun to look at the MAP file and see how everything changes with each alteration. There's few things I've noticed that would require alot of tweaking, but might be worth it to compress in the end. One is the spotvis (somehow turning it into bits, or a struct of unsigned int bit1 : 1, bit2 :1, etc., or a pattern of detection for each bit in the byte with a if (((x%(2^y))/(2^y)) >= 1) style function), and another is the actorat (where actors take up two bytes, and everything else takes up one). No idea how it would work yet (especially with all the pointers and ASM code), but I've always liked playing around with those; as they both take up a hefty load of space; much that doesn't seem required. Even having the spotvis just keep track of 32x32 (with the utmost middle left position being your position) might be interesting. The bosses statetypes could be combined a little for some extra space too.

For some reason, I got around 1000 extra bytes just by changing this in ID_CA.C the other day:
#ifndef AUDIOHEADERLINKED
huffnode	*audiohuffman;
#else
huffnode	audiohuffman[255];
#endif
Probably need to look into this into more detail, as I'm sure there's a catch. No idea what it does, but it doesn't seem to have any effect on the game's performance with sound or anything else so far. Hrmmm...

I'll have to try your ideas for the jukebox thing, and the japanesse thing Haasboy, but am trying to find ways to do this so that it doesn't have any affect noticable to the player from on the original game. Interesting ideas though. I'm SURE that there is many more of them to find, or things that can be plugged into far memory instead (my goal is infinate near memory! haha). :)
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 »

*LOL* !!!
Chris, you're great! :mrgreen:
Just had a look at this audiohuffman: IT ISN'T USED AT ALL!!!
You can just delete it and save 1020 bytes!!! WOW!

I guess Wolf is still full of unknown unneeded stuff :mrgreen;

Yeah, such a guide would really be worth much! So many people already found so many small pieces of this memory puzzle, I wonder how far we'd be, if everything would be put together.
Of course, as you said, most interesting are only those changes that have no visible effect to the player (as would be removing debug functions :mrgreen:).

Hmm, which variables of the objstruct do you mean, if you speak of variables only for the player? These should be very easy to eliminate, as you could just make them global (as there is only one player) and edit the places where these variables are used a bit.

The spotvis table is used in this wasteful manner because of speed, as it's used in the core loop of the raytracer. If you'd change the way things are saved in spotvis, you'd have to include many "slow" calculations inside the core loop, which could decrease the performance quite much... Although... maybe it would be worth a try ;)

Here are some more ways to get infinate near mem :mrgreen:

- Another unused array: WL_PLAY.C: "unsigned mapwidthtable[64];" ... *delete* *ping*
Result: 128 bytes near memory saved

- Remove "width", "height" and "name" from maptype in ID_CA.H, remove the external declaration of "mapwidth" and "mapheight" in ID_HEADS.H and add a "#define mapwidth 64" and "#define mapheight 64" there, remove the "mapwidth" and "mapheight" declaration in WL_PLAY.C and remove the "mapwidth" and "mapheight" assignment and the check inside SetupGameLevel in WL_GAME.C.
Result: This brings you only 20 bytes of near memory, but gives you 1200 byte more main memory (say far memory)(not including those 20 bytes) and should reduce the file size by 160 bytes *cough*

- Remove the "compatability" declaration in WL_PLAY.C and its external version in ID_HEADS.H, remove "ParmStrings2" in ID_US_1.C and the whole for-block containing the compatability switch in US_Startup.
Result: 144 bytes near memory, aprox. 64 bytes far memory

- Unused array: Remove "nearmapylookup" and its declaration in WL_PLAY.C and WL_DEF.H and remove its assignment in InitGame in WL_MAIN.C
Result: 130 bytes near and aprox. 16 bytes far memory

Some Ideas:

- Remove ylookup in ID_VL.C and replace its usage by calculations
Result: aprox. 400 bytes

- Same for farmapylookup
Result: aprox. 128 bytes

OK, that's enough for know ;)
User avatar
Adam Biser
Utility Developer
Utility Developer
Posts: 2415
Joined: Fri Jun 06, 2003 5:53 pm
Location: USA

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

Post by Adam Biser »

Chris wrote:For some reason, I got around 1000 extra bytes just by changing this in ID_CA.C the other day:
#ifndef AUDIOHEADERLINKED
huffnode	*audiohuffman;
#else
huffnode	audiohuffman[255];
#endif
Probably need to look into this into more detail, as I'm sure there's a catch. No idea what it does, but it doesn't seem to have any effect on the game's performance with sound or anything else so far. Hrmmm...
The linked audio header stuff seems to be left over code from the Catacomb trilogy, when the AUDIOT file had its own Huffman dictionary file (much like VGADICT). audiohuffman is not used in the Wolf code at all, so those lines can be deleted entirely.

EDIT: If you can get grhuffman to work as a pointer instead of an array, that'll free another 1020 bytes. Maybe it works without any changes anyway... I'd have to test.
User avatar
Dugtrio17
Code Master
Code Master
Posts: 902
Joined: Wed Mar 12, 2003 1:15 am
Location: Seattle

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

Post by Dugtrio17 »

Heh, I had to join in on the memory party :cheesy:
Of course my humble contribution was changing the int temp1,temp2,temp3; line in the thinking actor structure to byte temp1, temp2; since temp1 and temp2 never go above 255 anyway, and temp3's never used at all! Other things I've experimented with are messing with statetypes and trying to find SOMETHING to cut in the static object structure, since even a byte or a char would snag 401 bytes. Both proved relatively fruitless, and what was particularly shocking was that for some reason changing ticcounts in statetypes to bytes and adjusting values accordingly got NO memory... perhaps I recompiled wrong? It's something that could be explored, anyway, and until I find something else, you'll have my humble 604 bytes to use :)
Image
User avatar
Adam Biser
Utility Developer
Utility Developer
Posts: 2415
Joined: Fri Jun 06, 2003 5:53 pm
Location: USA

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

Post by Adam Biser »

EDIT: NOTE: This code does no work correctly. It has been left here in case someone figures out what it needs to work.
This seems to work and free another 1000+ bytes of near memory.
Delete the red stuff, add the blue stuff. (All in ID_CA.C)
#ifdef GRHEADERLINKED
huffnode	*grhuffman;
#else
huffnode	grhuffman[255];
#endif
in CAL_SetupGrFile:
	read(handle, &grhuffman, sizeof(grhuffman));
	MM_GetPtr (&(memptr)grhuffman,1024);
	read(handle, grhuffman, 1024);
Seems to work, unless someone more knowledgable in C sees a problem with it.

EDIT: OK, nevermind... that seems to not work. It looks fine until you go into the game and then back to the menu.
Last edited by Adam Biser on Fri Feb 18, 2005 2:08 pm, edited 1 time in total.
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] Saving 256 bytes of the data segment in ID_SD_A.A

Post by Zombie_Plan »

Another way to save memory is to use WSJ's Sprite Offsets to join Hans and Gretel's Statetypes, since they are exactly the same. This saves 404 bytes.
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 »

Yeah, the guide thing would be interesting. Some cool ideas all around. I decided to combine alot of the suggestions here into a new Source Code version; good times. Might be useful for people who are starting up a new project.

http://www.canadianphilatelics.com/choksta/memboost.zip (252k)

So far, the near memory is up to 7808 bytes without sacrificing anything that will affect the game (mostly just taking out unused stuff, making things cleaner, and getting rid of some original engine bugs). I'm trying to consider everything, there's still alot of places that could be fun to play around with that could make things more practical though; as you also mentioned Ripper. Here's a list that should give anyone a good idea of what's in the zip file so far:
Saving some near memory:

- Removed CO.ASM, WOLFHACK.C & WHACK_A.ASM from Wolf3d.prj (Ripper)
- Deleted temp3 (Dugtrio17), and shrunk speed and tilex/y in WL_DEF.H (906)
- Altered LevelCompleted() in WL_INTER.C, saving 544 bytes.
- Took out audiohuffman in ID_CA.C for 1020 bytes, since it's never used.
- Deleted the pcdtab table in ID_SD_A.ASM for 256 bytes (Ripper)
- Tested temp2 as a byte (Dugtrio17), needed to be a signed/char (302)
- Added the "removing the scalers" tutorial, gaining 1791 bytes (Ripper)
- Removed unused array mapwidthtable[64] from WL_PLAY.C (Ripper)
- Threw many gamestate variables (WL_DEF.H) into char variables.
- Removed all references to "nearmapylookup" for 128 bytes (Ripper)
- Combined Hans/Gretal and Schabbs/Gift with WSJ new actor offset idea (560)
- Used far tags for VgaCeiling[] (WL_DRAW.C) and songs[] (WL_PLAY), 192 bytes.
- Removed DumpData and ShowMemory from ID_MM.C, 168 bytes.
- Removed the compatibility (COMP/NOCOMP) tags, and their info (Ripper)
- Added a REMDEBUG define, so you can save 768 bytes in Version.H if you wish.
- Added a REMJUKEBOX define, for 64 more bytes (Haasboy)
- Added a REMBOSSES, 944 bytes for those who only need a few bosses.

A few minor touch-ups to the Source Code:

- Pushwalls now always move 2 spaces (end of WL_ACT1.C to change amount)
- Bosses now react from all angles (MCS)
- Cleaned up lump data in GFXV_*.H files (Adam Biser)
- Added a check for memory before Preload with Tab-M (Ripper)
- ElevatorBackTo maps always return to the next floor (Brothertank)
- Fixed a bug in the original VGAClearScreen function (Ripper)
- Fake Hitlers will stop shooting beyond MAXACTORS, instead of bombing out
- Removed mapheaderseg width/height in ID_CA.H, as they're not used anymore
- Spear of Destiny bugs fixed (10 compile errors, ratios 9+ in saved game)
- You can now alter the map width (beyond 64) with MAPSTRETCH in WL_DEF.H

To do list:

- Testing out the stability of using grhuffman as pointers (Adam Biser)
- Regrouping bosses into one state, and some of their functions together
- Testing and implimenting some of the changes in MCS's ID files (MCS)
- Record how many times you've saved and if you've used debugcodes
- Play around with compression for spotvis, or combine it with tilemap
- Using more global variables for the player in the actor structure
- Placing more strings and data arrays into far memory
- Creating a check to see if the map dimensions are compatible
- Work out compatibility issues (floorcodes, passages) for mapstretch
- Making more REM defines for other possibilities (no Menu, for instance)
It should play exactly the same as the original EXE (besides the touch-ups that are listed in the quote above). I'll keep upgrading it as I find new things to play around with, or hear about suggestions from you guys. This could make an interesting replacement to the original WOLFSRC.ZIP file from 1995; or something - I don't know. If you notice anything wrong with the code so far, or have any more ideas, feel free to post them. The more stuff we can find to conserve memory to new heights while keeping wolf true to the original, and completely stable; the more fun this gets. :)
Dugtrio17 wrote:change the thinking actor structure to byte temp1, temp2; since temp1 and temp2 never go above 255 anyway
You are right, they never go very high, probably not even beyond 20, but after a few tests (yes, I was a little skeptical about your theory) I noticed that atleast temp2 goes into the negatives; which can make the guards (especially deaf guards) react very slowly if you put temp2 as a byte. It's only noticable sometimes, but it does happen. You can test it out in WL_STATE.C, if you like:
ob->temp2 -= tics;
if (ob->temp2 > 0)
	return false;
if (ob->temp2 < 0)
	Quit("Quack");
ob->temp2 = 0;	// time to react
The quack will only display if you use some kind of signed integer for temp2, otherwise it will skip it (as does the byte). The "ob->temp2 = 0" has a purpose, as sometimes tics can be 2 or 3, and temp2 can sometimes be only 1. 1 minus 3 in bytes would be 254 and not -2, so you'd have to wait another 254 tics for that guard to react in that case instead of returning as false (which can turn into 510 or more if it suprasses the check again). It'd probably be safer to put them as "char", so that they can go from -127 to 128 and still be one byte; then you won't have super slow reacting guards sometimes. ;)
User avatar
Dugtrio17
Code Master
Code Master
Posts: 902
Joined: Wed Mar 12, 2003 1:15 am
Location: Seattle

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

Post by Dugtrio17 »

Ah, good catch there, Chris. Guess I should've looked at that one a little more thoroughly... The char should indeed work, so the memory won't be lost :)
Image
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 »

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.