I've been working on a Deathmatch map and its.. a giant Gamecube! ^^;
Here ya go!: http://home.comcast.net/~mlmars/gcbz3.zip
Here ya go!: http://home.comcast.net/~mlmars/gcbz3.zip
-
Do not use Works in Progress as a way of avoiding the releases system! Works in Progress can be used for sharing early betas and for getting suggestions for improvement. Releases of finished content are not allowed in this forum! If you would like to submit a finished addon, click here for instructions on how to do so.
Gamecube Battle Zone (updated)
- Thread starter Shuffle
- Start date
- Status
I'll say this:
Very interesting concept, yet bad use of textures/flats
It's the wall textures, really. The GFZROCKness of it all basically dirties the GCN. Some of the flats (Namely the ones to to the edge of the indent to the CD tray) also don't do justice
I like the laser :D, though I wonder if they fixed that damned laser bug yet :/
Very interesting concept, yet bad use of textures/flats
It's the wall textures, really. The GFZROCKness of it all basically dirties the GCN. Some of the flats (Namely the ones to to the edge of the indent to the CD tray) also don't do justice
I like the laser :D, though I wonder if they fixed that damned laser bug yet :/
Since I haven't played this in an actual netgame yet, I can't judge it for sure, but I already have a few suggestions. First, get rid of the GFZROCK way up in the sky. It looks like you've used Main textures there. The only time you should ever use Main textures in SRB2 is when you're making sector borders (GFZGRASS) or control sectors (off the map).
About the level itself, it might make sense to put a weapon ring or randomly respawning monitor or something up on the top of the lid, so people have a reason to go up there. I would also recommend spreading out the rings some more, so it's not as easy for one player to take nearly all of them.
Finally, I agree with the suggestions that you add a Player 1 Start and replace the GFZROCK with more appropriate textures.
About the level itself, it might make sense to put a weapon ring or randomly respawning monitor or something up on the top of the lid, so people have a reason to go up there. I would also recommend spreading out the rings some more, so it's not as easy for one player to take nearly all of them.
Finally, I agree with the suggestions that you add a Player 1 Start and replace the GFZROCK with more appropriate textures.
BlazeHedgehog
Member
It's not that. WadAuthor loads the WAD up into it's cache. It works like this:
- You save your map in WadAuthor, and it builds it's own nodes. You don't close this, so WadAuthor leaves the map and data in memory.
- You run Zennode on the map. Zennode rearranges everything and builds it's own (superior) nodes.
- If you save your WadAuthor map again, this trips WA's "not modified" defense, so it simply rebuilds the nodes under the premise of the old data. Because of how Doom handles data (incremental lumps and all), this throws everything completely off, and any data after the map itself becomes misaligned and corrupted.
BlazeHedgehog
Member
Like, from what AJ once said, Doom's textures are all 64x64, 128x128, etc for a reason -- it's how Doom indexes the WAD and reads the data. Rebuilding WadAuthor's nodes over Zennode's nodes messes up, because WadAuthor is storing the entire map in system memory and uses that to base it's study off of. When you save your map in this state, it overwrites data it didn't know existed, and thus screws up the index offset.
Then again, I'm hardly the techno geek you or AJ are, so I'm undoubtedly talking out of my ass.
Then again, I'm hardly the techno geek you or AJ are, so I'm undoubtedly talking out of my ass.
Nope, the way it works is there's a directory somewhere in the file (typically at the end, but according to the spec it can be anywhere... I wonder if I'd screw some programs up by putting it at the beginning) that lists all the lumps and has pointers to where in the file they begin, as well as their sizes.
So as long as the offsets in the wadfile directory are correct, there won't be problems. Texture sizes wouldn't make a difference there because textures themselves aren't even lumps, and if you meant patches, they're stored the same way all lumps are stored, so they could be any size.
The reason flats are 64x64 and 128x128 and so on? I don't know exactly, it probably has to do with how they're drawn, or maybe the size. Flats are stored as bmps without headers, so they don't have any size information. If you keep them square, you can take the square root of the lump length to find the dimensions.
Textures have to have widths that are powers of 2 because of how the TEXTURE1 entries are stored. The heights don't have to be powers of 2. There are a few SRB2 textures with weird heights, I think.
So as long as the offsets in the wadfile directory are correct, there won't be problems. Texture sizes wouldn't make a difference there because textures themselves aren't even lumps, and if you meant patches, they're stored the same way all lumps are stored, so they could be any size.
The reason flats are 64x64 and 128x128 and so on? I don't know exactly, it probably has to do with how they're drawn, or maybe the size. Flats are stored as bmps without headers, so they don't have any size information. If you keep them square, you can take the square root of the lump length to find the dimensions.
Textures have to have widths that are powers of 2 because of how the TEXTURE1 entries are stored. The heights don't have to be powers of 2. There are a few SRB2 textures with weird heights, I think.
- Status