The Result of No Sleep

Couldn't sleep for awhile so I made this to pass time before my second attempt at sleep. Quote 2.0 FTW.

EDIT: Just realised I totally forgot his hair. I'll add it in when I can. I don't want my little buddy to be bald.

EDIT 2: He has hair! Yay!

 

Not bad. He should have hair hanging down in the back, though...

 

Not bad at all - what are your plans for this? Fanart or...?

Looks nice either way.

 

Huh. Usually I see that black line as an outline, but I see what you mean now... I see how it looks.

Rune - It was fanart, but I made another pose from his sheet. If I get bored, which I probably will, and do the rest, I'd like to see how it looks in game. If so, would you be willing to slap them in for me?

One thing I've been wondering is about the doublesizing the game does - I've only played it in two resolutions - my own, 1280x1024 in Fullscreen, and Windowed 640x480. I don't know what it's like in other resolutions, but in those two the game is double-sized from the sprites. Is there a way to disable this doulbe scaling and use larger sprites, like using 32x32 sprites and not enlarging them?

 

I'll be happy to add them into the game, but it'll have to wait until I get my internet access back (unless I manage to pilfer them from a friend's house or something like that.)

It might be possible to attempt to detect the resolution and switch between two spritesets, but this would be a somewhat involving hack. I'm not sure if creating special cases for a single sprite would cause problems with the other sprites, though.

One thing to consider is that Pixel uses no blitting filter when copying sprites to the screen. This means it's a straightforward operation where the game tries to match every pixel on the screen being written to with a pixel from the source image (ie, the sprite.) I'm curious if it'd be possible to change the blitting function called - my DirectX is rusty but I'll give it a look if I don't finish work too late...

 

Don't rush yourself, I doubt this sheet will be done in awhile, considering my other obligations are more important.

PS: Quote with hair. Good Bad or Ugly?

 

I gave this a quick look last night. It would be possible, but not easy.

Basically, it means copying the function which blits a sprite to the screen and editing it to render without scaling. Then, Quote's sprite coordinates would be modified to use the 32x32 sprite (this part's easy.) Finally, the game would have to call the new rendering function when it wants to render Quote.

Autodetecting the resolution would also be possible, but hardly desirable because doing it via machine code would be tremendously complex due to space constraints. Basically the game would call the Win32 API at startup to poll the primary display unit for some specs and would branch to two different Quote-rendering functions depending on the resolution. Unfortunately any and all of these solutions would involve scrapping an entity or something like that for space. Or maybe one could get away with rewriting the code in a more compact way (for instance, when referencing a structure, the game very often loads the structure's base pointer in a register each time it accesses it - just caching it once can save on a couple of spare bytes.)

In short, it's doable.

 

Ah. I had thought that the list of resolutions for CS was larger than it was when I just checked it.

If the double-sizing is part of the blitting itself, then how does the game function in 320x240?

 

I'm not quite sure at the moment - I only gave the actual function a look, not the bit that calls it. I believe it scales up from 16x16 when in 640x480... or down from 16x16 in 320x240. Either way, it most likely treats the screen as a virtual surface and maps out the sprites to the window's size when rendering, which means they'd get stretched or squashed. I'll see if I can change the resolution when I get home to a larger or smaller one than the ones in the config.

You made me realize something though - there's no need to go through the Win32 API to poll the screen for its resolution: CS stores this directly when it determines wether to go fullscreen, windowed, 320x240, whatnot.

 

Quick question: If you look at the sprite sheet for Quote, after the pose for looking down (Only possible while jumping), there's the pose for looking in the background, an unidentified one, and one of him lying down.

What is the unidentified one? It's slightly different from it's countpart for facing right.

 

Quick question: If you look at the sprite sheet for Quote, after the pose for looking down (Only possible while jumping), there's the pose for looking in the background, an unidentified one, and one of him lying down.

What is the unidentified one? It's slightly different from it's countpart for facing right.

After jumping, when you afll, that sprite is displayed.

 

Ah. Okay. Thanks.

 

Ugh. I forgot how mindlessly numbing making different poses of the same sprite was. Thank god the Mimiga mask is just a face switch.

NOTE: For some reason the Mimiga mask doesn't have the mask on that "unidentified" one. I'm assuming either it just doesn't use that as a Mimiga or Sontreal was mistaken, probable the former.

 

HOLYCRAPITSDONEYAY

 

Ah. I think I was wrong. It might be used when using the Booster going sideways. Since when you have the Mimiga mask, the Booster has been taken from you, it's not necessary.

Edit: Speaking of unknown sprites, does anyone know where the eight red sprites of Curly are used? (located in the NpcRegu)

 

I did a bit of extensive searching and found how the coordinates are specified in 320 and 640. There's an offset holding the scaling value (1 or 2) which multiplies the size of a sprite before it gets passed to the blitting function.

It's weird though. I think the value must be set before the images are loaded. Switching on the fly screwed up a lot of stuff and my graphics were skewed and weird because the bitmap loaded in memory isn't scaled properly and the wrong part is grabbed.

Careful tweak of the coordinates to grab the sprite from could fix that, and allow for different scales...

 

I think, if we were to go through with creating updated sprites at 32x32, we could eventually change the global scaling value, but if we're just going to test out the updated Quote, creating a second blitting function specifically for him would be the best idea.

 

I also have two values which seem to control how far the display goes (ie, 320 in width, 240 in height...) I think it would be possible to force the game to run in scaling mode 1x but in 640x480, then every scaled sprite would have its display rect resized to contain the new sprite.

This would allow the game to run in high-res, but would involve a lot of work.

 

A lot of work coding or a lot of working making said hi-res graphics? *falls over in agony at thought of re-doing EVERY sprite in CS*

 

Meh, redrawing every sprite is about as bad as inserting code: finding new space to insert the extra code, hammering a "call" in there to jump to the new code, making sure to keep the stack clean, making sure nothing tries to jump into (old) deleted code (or newly inserted code, for that matter), tweaking pointers... Believe me, when I coded my custom boss and found a bug that involved removing a line of code, I often opted for the insertion of NOP (No OPeration) instructions instead of the pain of going through the entire code again to fix jumps and calls.

Alternatively, every sprite could be scaled to 2x without being redrawn (flat-out stretching them, basically.) Then the code could be written to work solely in 1x mode with double-sized sprites (...all of which would have to have their display rects re-set... THAT'S a pain Easy as hell and even more tedious - the worse kind of hack job. )

I'll see if I can try working with double-sized bitmaps this weekend if I can crack the entirety of the rendering code (doing good progress so far!) If so, it'll just be a matter of adding the sprites as they're drawn...