Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
BlueBeast

Sprite size limits?

Recommended Posts

Using plain Doom2 v1.9. is there a size limite to the sprites? I'm sure theres issues with overload or some other problems, but whats the maximum width, and or hights for a sprite?

Share this post


Link to post

Well, this doesn't really answer the question, but just for info, the tallest original sprites are CYBRM0 and CYBRN0 both at 134 tall and SPIDB2B8 is the widest at 257 so the limits must be at least that.

Share this post


Link to post

I know all of the wad editing programs have size limits on bmps you import into the wad, dunno about the actual game (though huge sprites in vanilla would probably cause crashing, dunno about various ports)

Incedentally in ultimate hell i used sprite scaling to turn a small metal tower sprite into a huge one with no ill effects, except for extreme blockyness, but whats GL for? XD

Share this post


Link to post

Actually I think the sprite size limit is below 260 units tall. Haven't found the width limit though yet :\

For ports other than ZDooM and also most GL ports, the sprites will be clipping from the first 128 pixels high or so.

Share this post


Link to post

Sprites for vanilla Doom and all ports not ZDoom can be AT MOST 255 pixels tall, but for practical purposes unlimited in width (there's a limit at 32767, you won't run into it :).

Share this post


Link to post
Fredrik said:

Sprites for vanilla Doom and all ports not ZDoom can be AT MOST 255 pixels tall, but for practical purposes unlimited in width (there's a limit at 32767, you won't run into it :).

Pfft, I was making a hi-res sprite and it was 32768 wide. That sucks, the limit should be raised.

Share this post


Link to post
Nanami said:

Pfft, I was making a hi-res sprite and it was 32768 wide. That sucks, the limit should be raised.

Sounds more like you should be using some other engine :)

Share this post


Link to post
FireBastard said:

Why is it only 255?

Because single bytes are used to specify how many pixels there can be in each column.

Share this post


Link to post
Fredrik said:

Because single bytes are used to specify how many pixels there can be in each column.


uh, the height of the image is stored in 2 bytes. I believe you're thinking of the number of pixels stored in a post, which is limited to 255, but there can be multiple posts in a column

Share this post


Link to post
Cyb said:

uh, the height of the image is stored in 2 bytes. I believe you're thinking of the number of pixels stored in a post, which is limited to 255, but there can be multiple posts in a column

Yep, however the Y offset for where a post starts is also stored in a byte, so you can't cheat by splitting a column up into several posts to achieve highresolutionness.

Share this post


Link to post
Fredrik said:

Yep, however the Y offset for where a post starts is also stored in a byte, so you can't cheat by splitting a column up into several posts to achieve highresolutionness.


ah yes good point

speaking of which there are two unused bytes in every post, I take it zdoom uses one of these to up the offset?

edit: actually, something isn't sitting right with this. program I'm currently working on extracts doom format to bmp, and I wrote the algorithm without hires graphics in mind, so my assumption is that it wouldn't be able to extract any graphics higher than 255 rows. However, I just used it to extract the titlepic from massm2 which is 640x480, and it extracted it perfectly...

edit: btw I imported the titlepic with deutex 4.4.0

Share this post


Link to post
Cyb said:

ah yes good point

speaking of which there are two unused bytes in every post, I take it zdoom uses one of these to up the offset?

That's what I thought at first, but it didn't seem to work when I tried.

I got this out of deep though:

In terms of code decoding I assume? Pretty simple really since that was my goal when I invented them:-)

Just take the stock decoding code and keep track of the highest Y offset per column. Compare the Y offset to the highest and add the highest offset so far to the current Y offset if it's less. ZDOOM code has a clear example (many places actually). Just a few lines of extra code is all it takes.

Share this post


Link to post
Cyb said:

uh, the height of the image is stored in 2 bytes. I believe you're thinking of the number of pixels stored in a post, which is limited to 255, but there can be multiple posts in a column

That makes sense. I think I saw a post on NEWDOOM that the maximum patch size is 504 and aren't sprites exactly the same format?

Share this post


Link to post
FireBastard said:

That makes sense. I think I saw a post on NEWDOOM that the maximum patch size is 504 and aren't sprites exactly the same format?

They are the same format. But the max size, if you do it the ZDoom way, isn't 504 pixels, but much higher (don't know for sure how much higher though).

Share this post


Link to post

Pretty sure you can. That guy on Newdoom sounded like he knew what he was talking about. Following what Cyb said, seems all you need is a second post at 254 (that's less than 255) and there you go. Don't know if DOOM will show it. Could be a forced chop/limit as it is with textures.

Share this post


Link to post

That'd give you 509 pixels.

But in either case: even though they're valid, rendering of such patches is not supported by regular Doom (I'm quite sure).

Share this post


Link to post

aye, 509 is the graphics format limit in terms of height (due to previously mentioned byte limit). This of course explains my program being able to extract something 480 pixels tall. Also here's deutex output when I tried to import an 800x600 titlepic:

C:\doom\utils>deutex -make bigtp.txt bigtp.wad
DeuTex 4.4.0 Copyright 1994,95 O.Montanuy, Copyright 1999-2000 A.Majorel
Ported to DOS, Unix, OS/2, Linux, SGiX, DEC Alpha.
Thanx to M.Mathews, P.Allansson, C.Rossi, J.Bonfield, U.Munk.
This program is freeware.
Type "deutex --help" to get the list of commands.
Doom directory is c:\doom\
Translating mm2tp.txt into a PWAD bigtp.wad
Reading WAD c:\doom\\doom.wad: (2306 entries)
Creating PWAD bigtp.wad
Color palette is Doom
Making Graphics

Error: Picture height can't be more than 509

Share this post


Link to post

basically you probably have the same limits as you get with wall textures.

Share this post


Link to post

I just tried a sprite 384 tall in stock DOOM2 - cell ammo. It worked. Looked a little at the format, don't think 509 is correct - need to double check my thinking on this. Basically I'm thinking about the skipped data (still counts in the offset) and the terminator.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×