Here we go again...
Battlezone D3D9 (http://www.bzuniverse.com/~betadudes/unprotected/bzone_d3d9_2009-12-11.7z)
I put it on BetaDudes this time so downloads should be more reliable than hosting it on my NAS.
Changes:
- Added support for 32-bit frame buffer, enabled by default. Disable in render.cfg "[D3D]" section with "Buffer32=0"
- Enabled dithering for 16-bit frame buffer
- Fixed fog color not getting set properly (e.g. in first Soviet mission)
- Turned off base address randomization so I can get meaningful results from crash reports :)
- Removed unused library dependencies
- Fixed calculation of v_mag_inv for small v_mag, which may fix some rare collision issues
- Fixed invalid floating-point operations in AI lateral movement, which should increase mission stability
- Added support for setting vsync, enabled by default. Disable in render.cfg "[D3D]" section with "Vsync=0"
- Re-added support for setting Z-buffer, since removing it broke software renderering. Hardware rendering is much faster with it enabled, almost 2x on my desktop computer.
- Switched seismic wave and explosion shake to Perlin noise. The explosion shake is currently very weak, so it'll get tweaked later.
Usual reminders:
1. This build requires the Visual C++ 2008 SP1 Redstributable Package (http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en)
2. If using a retail install, rename the "splash" folder to "splash_" to disable Windows 7's compatibility layer
3. If running on Windows Vista or 7, make the install folder writable
4. If having trouble, try the DirectX End-User Runtime Web Installer (http://www.microsoft.com/downloads/details.aspx?FamilyID=2DA43D38-DB71-4C1B-BC6A-9B6652CD92A3&displaylang=en)
Unfortunately there is no additional information. Still get an error at addrexx 0000005.
'bzone.exe': Loaded 'C:\Windows\SysWOW64\msctf.dll'
Unhandled exception at 0x00a21c18 in bzone.exe: 0xC0000005: Access violation.
Debugger:: An unhandled non-continuable exception was thrown during process load
The thread 'Win32 Thread' (0x94c) has exited with code -1073741819 (0xc0000005).
The program '[3160] bzone.exe: Native' has exited with code -1073741819 (0xc0000005).
I managed to coerce a call stack out of the application, and the access violation occurs deep inside NTDLL.DLL as part of something ANET2.DLL is doing. After loading debug symbols, the call stack indicated a validation failure inside AllocateHeap. Unfortunately, the call stack trails off after that.
If this is an Activnet thing, it's going to be a hard problem to fix.
That sucks, and I"m assuming there is no workaround, even if it involved disabling MP.
Which anet2.dll are you using? (Size and date on the file)
Same for your winets2.dll.
That particular test was done with a BZ98 install since I was at work.
ANET2.DLL: 95804 bytes, 7/7/1998 3:58PM
WINETS2.DLL: 32768 bytes, 6/15/2004 9:24PM
Here's the anet2.dll that matches the winets2.dll you have.
anet2.dll (http://theoutcasts.us/dx/terrazone/ANET2.zip)
VS2008 dlls (http://theoutcasts.us/dx/terrazone/vs2008_dll.zip)
That fixed it. Awesome! :-D
Oh great! hehe
Looks like someone needs to update the BZ98 installer... :lol:
Anyway, I'll start including that in future experimental builds. I'm not sure why the original one would start for some people and not others, but I guess that will remain a mystery...
I noticed the new DLL was a lot larger. Where did it come from?
The anet open source.
The activnet folder in the current build should be updated with the latest includes and libs aswell.
Is it the version of Anet from here (http://www.kegel.com/anet/)?
I should make the Activnet a separate download since it's not going to be changing any time soon.
Yes.
It has one bad effect that i saw, it doesn't drop a player with 100 loss.
Ah. How often does that happen, though? :-D
Here is the vs2008 updated dlls
VS2008 dlls (http://theoutcasts.us/dx/terrazone/vs2008_dll.zip)
Whenever players ban each other. :D
Quote from: Dx on December 11, 2009, 01:19:09 PM
Here is the vs2008 updated dlls
VS2008 dlls (http://theoutcasts.us/dx/terrazone/vs2008_dll.zip)
Nice. I'll try building them on my own as well since it's a good thing to have handy.
QuoteWhenever players ban each other. :D
Ah, that never happens. :-D
Thanks, that ANET update got it to launch for me.
I just went through the Soviet campaign [edit: using XP Pro] and it completed okay.
Everything so far seemed to work. I'm only noticing a few annoyances.
1. LargeAssets doesn't seem to function. Enabling it results in untextured items
2. Lack of support for wide screen. Being able to manually specify the res in the render.cfg would be good enough if it meant I could pick 1920x1080.
3. Mouse sensitivity seems to be low, but that's most likely something on my end.
1. Hmm. How big is your bzhw16l.zfs?
2. I plan to redo the resolution mechanism for hardware, though I'm not sure how I'm going to do it yet. :)
3. Strange. It's been fine for me since I straightened out the mouse input code.
It's been years since I have played bz1 so my memory of how fast the Razor turns could be off.
If I were to install TRO, would it benefit from the engine update?
I recall it being pretty snappy, though less so at full throttle.
TRO incorporates significant shell and game logic changes so it won't work with this update. I'd need the source code to do anything about that.
That stinks, I'm assuming you won't be able to easily acquire that.
Someone somewhere has it, so it's not impossible. :-D
One bug that always bugged me in bz1. If you have the targetting window up, all engine flames fail to render. I'll post the size of my file in one sec. Looking that up now.
Size: 3.54 KB (3,632 bytes)
Size on Disk: 4.00 KB (4,096 bytes)
That means you don't have the large assets pack installed. It should be 3.4MB (3,570,683 bytes).
Yes. All bz1 ships are slower than you think they should be. Your mouse is fine.
Not much worth mentioning, but I was flying around Armageddon and throwing thumpers around FTHOI. As it hit a repair or ammo or any powerup, the "base under attack" beeping went off.
Ha- might be anet code causing that though.
Got a crash mid-end NSDF 4. Lemme see if I can get an error code somehow.
Quote from: bb1 on December 11, 2009, 04:59:55 PM
Not much worth mentioning, but I was flying around Armageddon and throwing thumpers around FTHOI. As it hit a repair or ammo or any powerup, the "base under attack" beeping went off.
That's a side effect of AI and interface changes I made while fixing the "half-alliance" exploit. I need to fix that.
So I ran bz and attached Visual C++ 2008 Express Edition to it, and near the end of NSDF 4 I got another crash. I've still got the stuff up, so let me know if there's anything that I should post/do with it.
This crash was before the attack wave comes in from behind, but the other crash wasn't. Maybe the tug dropping the object caused it?
Also, there's almost always a voiceover playing. The units' responses play only once, but the mission ones play waaayyy too many times.
Sabre, if you get the AV, perform the following steps. Remember to keep the AV screen up.
1. Load up Visual C++ 2008 Express as an administrator if you are using Win 7 or Vista
2. Click on Tools
3. Select Attach to Process
4. Select bzone.exe
You should find some info under the Output button or tab.
'bzone.exe': Loaded 'C:\Windows\SysWOW64\crypt32.dll'
'bzone.exe': Loaded 'C:\Windows\SysWOW64\msasn1.dll'
The thread 'Win32 Thread' (0xe44) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x5ac) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0xfcc) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x6ac) has exited with code 0 (0x0).
First-chance exception at 0x00491c09 in bzone.exe: 0xC0000005: Access violation reading location 0xfc7cf020.
Unhandled exception at 0x00491c09 in bzone.exe: 0xC0000005: Access violation reading location 0xfc7cf020.
Edit: Woah, this is some cool stuff.
Commando, I attached it to bzone before starting the mission -- that's OK too, right?
Crash happened in NSDF 4, just before the squadron comes in from behind your base, after having secured the relic.
You should be able to connect at any time, not just after it crashes.
If you unpack the program database file (http://www.bzuniverse.com/~betadudes/unprotected/bzone_d3d9_2009-12-11.pdb.7z) to the same folder as the executable, you'll be able to see the call stack.
Update: Testing with the debugger attached will be very helpful in the future. I should start releasing the internal build as well, since it's basically an "optimized debug build" that produces somewhat more meaningful output.
Word. Again it is!
Sabre, you have to install the ANET update that DX posted. After I installed that file, bzone would load.
Did that. What I posted happened in NSDF 4. I'll edit the post to make that more clear.
Edit: Also, it's true. 4m4z1ng at the bz1 boards and I are the same person in real life. Sorry for any confusion :p
Just tried out the new exe and the strange model/terrain bug is back.
http://www.bz911.com/bzonetest3.wmv
It was fixed in the last version.
Eddy
I'm not sure this is actually a bug, but might as well mention it anyway. It seems vaguely familiar. When I move my cursor over some settings in the Options shell tab, this happens.
Normal: (http://www.freeimagehosting.net/uploads/th.07930dedee.png) (http://www.freeimagehosting.net/image.php?07930dedee.png)
After mouseover of top two: (http://www.freeimagehosting.net/uploads/th.580b319371.png) (http://www.freeimagehosting.net/image.php?580b319371.png)
After mouseover of all four:(http://www.freeimagehosting.net/uploads/th.c7f7d8ded8.png) (http://www.freeimagehosting.net/image.php?c7f7d8ded8.png)
I had removed support for the Zbuffer flag in the previous build, but that broke the software renderer so I had to put it back. I'll come up with a different solution next time, but for now you should set Zbuffer to 1 in render.cfg. It'll run a lot faster, too. :)
Now that we've figured out and fixed the crash on startup, I'm going to take care of all those shell glitches.
The fadein effect, when it comes to terrain being obstructed by the skydome, and polygons seems to be a little jumpy. You can see the polygons if you circle strafe around a Grizzly tank. You can see the terrain issue on almost any map, I noticed it the most on the mars maps, especially when the alien factory on the second mars map fades in. It's amaziong how slowly ships turn when compared to bz2. The Grizzly turns as slowly as my Buick whish is kind of annoying.
Ken, has the scaling changed much between Bz1 and Bz2? I think I remember Avatar stating that the scaling of maps was slightly different when porting a map from bz1 to bz2.
BZ1 uses a 10-meter grid, while BZ2 uses an 8-meter grid by default.
Is that something specified in the .ter file or .bzn file I'm assuming. I'm guessing it is adjustable based on the, by default comment.
It was adjustable in BZ2, but hard-wired in BZ1.
Would it be possible to update bz1 so it doesn't have to be run "As an administrator"? I think this would make it compatible with Steam and at the same time will make launching and restoring less annoying. If I alt-tab it, I have to right click on it's tab on the task bar and run it as an administrator just to play it again. I think GSH made bz2 compatible with Vista by having it write it's documents, savegames, preferences, etc to the My Documents\My Games folder.
Adjusting mouse sensitivity under Options\Play helps with the turning.
Switching the file paths is on the list of things to do. :)
Quote from: Red Devil on December 11, 2009, 10:45:13 PM
Adjusting mouse sensitivity under Options\Play helps with the turning.
Didn't do much for me... :-(
Speaking of files, it doesn't appear to be saving mission archives from one startup of bzone to the next.
Nor GFX settings if I'm remembering correctly.
Yeah, that was one of my gripes regarding bz1. There is no profile so if you don't make an in-game savegame, the next time you open bz1, you lose all of your progress. Luckily bz2 didn't suffer from this too.
Just remembered: if you type iamadirtycheater when looking at the mission briefing screen, it'll display all the missions, which you can ten select.
Yup, that's what I've been doing :D
First of all, two problems:
-on both combat and world radar, everything except team 1 vehicles/buildings are black, hull/ammo meters for units are also black, like when there is a team 3 or greater in the editor. may be due to la, as it causes problems, as noted by commando, have to check.
-the only audio that plays is the music.
Second, fix requested:
-when there are about 20-30 'dayquake' explosions at once, the ground shockwaves resulting get all mixed up with each other, resulting in a very high hill that is constantly shaking and once in awhile sending out ground shockwaves...very annoying.
try making a custom mine that uses the dayquake as the explosion, with a rapid fire rate, set a whole lot in one place(20-30), and place an enemy on it. MAKE SURE YOU BZBODY CHEAT IS ON!! after you are blown rapidly across the map a few times, check out the big hill wherever you placed the mines. OR you could just edit 'dayquake.odf', and just place 1 mine.
Sandmod map had a thumper that did that. HOld down and watch the hell and the crash.
Bz1 just crashed on me. Due to it providing no log files, I was unable to get any useful info out of it. I tried bring up Visual Studio 2008, but bz1 refused to minimize allowing me to see the VS 2008 interface so I was unable to attach bzone as a process to get some info.
Full-screen is very "grabby" right now, so I recommend running BZ in windowed mode.
(Just create a shortcut to bzone.exe and add /win to the command line)
Mine only runs in windowed mode.
One of my savegames refuses to load, produces a crash when trying to load.
00491C09 mov eax,dword ptr [ecx*4+7CBFC0h]
'bzone.exe': Loaded 'C:\Windows\SysWOW64\mcicda.dll'
The thread 'Win32 Thread' (0xb5c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0xac0) has exited with code 0 (0x0).
First-chance exception at 0x00491c09 in bzone.exe: 0xC0000005: Access violation reading location 0xfc7cf020.
Unhandled exception at 0x00491c09 in bzone.exe: 0xC0000005: Access violation reading location 0xfc7cf020.
That's in GetTilePtr(), indicating that something is looking up a terrain tile far outside the mapped area. Do you have a call stack?
I can try loading your save file if you put it somewhere I can get it.
It'll take me a moment to upload it onto the betadudes folder.
Try this savegame. http://www.bzuniverse.com/~betadudes/unprotected/game8.sav
That's odd. Now it will load without dieing. The only major change is that I restarted my computer and that my resolution was low instead of being maxed. Now that I have my res back up, I'm going to try again.
It dies if my resolution is 1280x1024, or whatever bz1 maxes out at, but it is fine if it is at 640x480, weird. My other savegames don't have this issue which is odd.
This issue is weird, sometimes the savegame will load, other times it won't. I had some luck loading my save1 first then loading save8. It loaded until I shut down bz1, then restarted it. Once it restarted, I tried loading save8, again death on load.
I gave you the only info bz1 gives me. It doesn't produce an AV dialog box. Win 7 says the program stopped responding and gives me the option to close, and that's the only option, unfortunately.
BZ definitely needs a better logging and reporting system...
Anyway, I'll give the save file a run here to see what happens.
This is what was in the callstack info.
> bzone.exe!00491c09()
[Frames below may be incorrect and/or missing, no symbols loaded for bzone.exe]
bzone.exe!0043f6cb()
bzone.exe!00404d0d()
bzone.exe!0044db40()
bzone.exe!00450220()
bzone.exe!0044cdc0()
bzone.exe!0044b3d5()
bzone.exe!0044b1d9()
bzone.exe!00401774()
bzone.exe!00428910()
bzone.exe!00401030()
bzone.exe!004561f5()
bzone.exe!00457100()
bzone.exe!0052614d()
kernel32.dll!76133677()
ntdll.dll!77b79d72()
ntdll.dll!77b79d45()
Ah. If you have the .pdb file in the same directory as the executable, you should be able to tell the debugger to load symbols using the Modules tab on the bottom left. Just right-click on bzone.exe in the list and it should give you the option.
I loaded that save game and immediately got an invalid floating-point operation in Vector_Rotate(). One of the AI vehicles ("svlt1328_wingman") has a bad target direction vector since one of its weapons (an instance of "gtaggun") hasn't initialized its hardpoint world matrix yet. AbleToHit() just ends up using whatever trash happens to be in memory.
That is a very serious flaw in the Weapon class, and I'm surprised that this kind of thing didn't come up more often.
Omething easily fixed?
Apparantly not easy to fix. He said very in italics...a grave adjective modifier indeed... You misused the italicizing to make it seem difficult to fix!
Aren't HPs rotated some direction from the real-world model? DX could clarify there.
It was an easy fix, but a dumb mistake on my part (in 1997, mind you) in a core system that could have produced all kinds of problems. Fortunately, the window of opportunity for it to cause trouble was extremely narrow. :)
Setting the matrix in the Weapon's constructor function was the solution.
Quote from: bb1 on December 12, 2009, 10:06:25 AM
Sandmod map had a thumper that did that. HOld down and watch the hell and the crash.
no, it won't go away! You will have a 1000000000000000000000000000 ft mnt there for the rest of the mission! My guess is that all the shock waves get "tangled" up with each other, and can't continue shockwaving away from the explosion center.
That pillar came from terrain height being driven below zero altitude, where it would wrap around to 409.5 meters. Stacked waves drove the terrain further down, increasing the likelihood of that happening.
Quote from: Ultraken on December 14, 2009, 05:37:09 PM
That pillar came from terrain height being driven below zero altitude, where it would wrap around to 409.5 meters. Stacked waves drove the terrain further down, increasing the likelihood of that happening.
whoa, that's weird! Driven
below zero altitude? Is there a dip when the blast 'starts'? So lots of dips make it too low? Hmm, sound wangy. If you get a rigged daywrecker dispensing highspeed mortar, the hill goes
up, until it reaches a certain height, and then it stops and won't go away.
The terrain uses a 12-bit integer representation for height, so there's a minimum altitude of zero and maximum altitude of 409.5 meters. The waves start out small, but add up when a bunch of them overlap. Clamping the terrain so it can't wrap around did fix it.