Difference between revisions of "Talk:Sega 32X"

From DoomWiki.org

(Created page with "== Technical details == Are you sure about compressed lumps being unmarked? My Jaguar to PC conversion utility works just fine on the 32x wad. In addition the map lumps are mar...")
 
(Rocket are shot backward)
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
== Technical details ==
 
== Technical details ==
 
Are you sure about compressed lumps being unmarked?  My Jaguar to PC conversion utility works just fine on the 32x wad.  In addition the map lumps are marked as compressed.  It does differ from the Jaguar in that most lumps are uncompressed, which I assume is done to keep memory utilization to a minimum on the 32x at the cost of additional cart space.  Everything else seems correct. [[User:Blzut3|Blzut3]] 21:35, 28 October 2012 (UTC)
 
Are you sure about compressed lumps being unmarked?  My Jaguar to PC conversion utility works just fine on the 32x wad.  In addition the map lumps are marked as compressed.  It does differ from the Jaguar in that most lumps are uncompressed, which I assume is done to keep memory utilization to a minimum on the 32x at the cost of additional cart space.  Everything else seems correct. [[User:Blzut3|Blzut3]] 21:35, 28 October 2012 (UTC)
 +
:Looking at the file in a hex editor, I see <tt>2E 00 00 00 00 00 00 00</tt> in the name field for the "." lumps. The JagDoom IWAD has instead <tt>AE 00 00 00 00 00 00 00</tt>. As for map lumps: header, VERTEXES, NODES, REJECT, and BLOCKMAP are left uncompressed (of course, there's nothing to compress in the header anyway); while "ÔHINGS", "ÌINEDEFS", "ÓIDEDEFS", "ÓEGS", "ÓSECTORS" and "ÓECTORS" are indeed compressed. --[[User:Gez|Gez]] 21:57, 28 October 2012 (UTC)
 +
::Yes. The point is though that the "." lumps are uncompressed in the 32x.  Remember that the compression is an LZSS layer provided by the wad manager.  It appears that more memory was needed in the 32x so they left the pixel data uncompressed so it can be read directly off the cartridge rom (instead of loading into ram).  Technically the image meta data probably could be compressed slightly in some cases. From what I can tell there is no difference in the wad format from the Jaguar to 32x, just a difference in what lumps are compressed or uncompressed. Those that are compressed are properly marked. [[User:Blzut3|Blzut3]] 22:19, 28 October 2012 (UTC)
 +
:::Okay, mystery solved, I was misled by error reports from SLADE which I had coded too strictly. In Jaguar Doom, posts end with 0xFFFFFFFF, in 32x Doom, they end with 0xFFFF and the next post is written instead of the final post's length. So since my code was looking for an 0xFFFFFFFF, it didn't stop where it should and reported that the data wasn't big enough. Oops. --[[User:Gez|Gez]] 23:24, 28 October 2012 (UTC)
 +
 +
== Rocket are shot backward ==
 +
 +
This is weird. There is no cyberdemon in this version, so why did they do this? They should have done it from the player's perspective instead. There's a similar mistake in the SNES version where you always see the rocket from the rear. So it's the cyberdemon who shots backwards.
 +
--[[User:Axdoomer|Axdoomer]] ([[User talk:Axdoomer|talk]]) 19:39, 17 December 2016 (CST)
 +
 +
: Clearly a bug, one of the myriad things forgotten about or just not properly considered in this madly rushed port. It'd have been appropriate to replace the front view of the rocket sprite with its back angle in this port, but clearly nobody thought of it. --[[User:Quasar|Quasar]] ([[User talk:Quasar|talk]]) 09:14, 19 December 2016 (CST)

Latest revision as of 10:14, 19 December 2016

Technical details[edit]

Are you sure about compressed lumps being unmarked? My Jaguar to PC conversion utility works just fine on the 32x wad. In addition the map lumps are marked as compressed. It does differ from the Jaguar in that most lumps are uncompressed, which I assume is done to keep memory utilization to a minimum on the 32x at the cost of additional cart space. Everything else seems correct. Blzut3 21:35, 28 October 2012 (UTC)

Looking at the file in a hex editor, I see 2E 00 00 00 00 00 00 00 in the name field for the "." lumps. The JagDoom IWAD has instead AE 00 00 00 00 00 00 00. As for map lumps: header, VERTEXES, NODES, REJECT, and BLOCKMAP are left uncompressed (of course, there's nothing to compress in the header anyway); while "ÔHINGS", "ÌINEDEFS", "ÓIDEDEFS", "ÓEGS", "ÓSECTORS" and "ÓECTORS" are indeed compressed. --Gez 21:57, 28 October 2012 (UTC)
Yes. The point is though that the "." lumps are uncompressed in the 32x. Remember that the compression is an LZSS layer provided by the wad manager. It appears that more memory was needed in the 32x so they left the pixel data uncompressed so it can be read directly off the cartridge rom (instead of loading into ram). Technically the image meta data probably could be compressed slightly in some cases. From what I can tell there is no difference in the wad format from the Jaguar to 32x, just a difference in what lumps are compressed or uncompressed. Those that are compressed are properly marked. Blzut3 22:19, 28 October 2012 (UTC)
Okay, mystery solved, I was misled by error reports from SLADE which I had coded too strictly. In Jaguar Doom, posts end with 0xFFFFFFFF, in 32x Doom, they end with 0xFFFF and the next post is written instead of the final post's length. So since my code was looking for an 0xFFFFFFFF, it didn't stop where it should and reported that the data wasn't big enough. Oops. --Gez 23:24, 28 October 2012 (UTC)

Rocket are shot backward[edit]

This is weird. There is no cyberdemon in this version, so why did they do this? They should have done it from the player's perspective instead. There's a similar mistake in the SNES version where you always see the rocket from the rear. So it's the cyberdemon who shots backwards. --Axdoomer (talk) 19:39, 17 December 2016 (CST)

Clearly a bug, one of the myriad things forgotten about or just not properly considered in this madly rushed port. It'd have been appropriate to replace the front view of the rocket sprite with its back angle in this port, but clearly nobody thought of it. --Quasar (talk) 09:14, 19 December 2016 (CST)