Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Sprite scaling relative to resolution

Author
Message
DarthJim
13
Years of Service
User Offline
Joined: 26th Dec 2010
Location: Australia
Posted: 27th Apr 2011 02:24
Hi. Woo hoo, first post Please excuse excessive mirth, we Australians are easily excitable.

I'm trying to work out how to set up a resolution selection mechanism, which automatically scales Sprites to the appropriate size. It seems that Sprites will only scale if you manually re-size the game window by dragging the sides or corners.

I'll use the DarkInvaders example, well, for example, because it's already got some Sprites lined up nicely.

In DarkInvaders.cpp, the screen resolution is set to 1024 x 768 x 32 with:
[/code]
dbSetDisplayMode (1024, 768, 32 );
[code]

Forget the line that sets full screen for now, I'll worry about a Window first.

Everything looks fine, and everything scales evenly if I drag the Window. However, if I wanted to set the resolution to say 1280x960, the Sprites stay the same original size.

I've tried using dbSetDisplayMode by itself, with dbSetWindowSize, and dbSetWindowSize by itself, no dice.

The only way I can see around this would be to scale all sprites manually, by a factor that is relative to the new resolution size. If I develop my interface to a default size of say 1024x768, different resolutions could be measured against this to determine a scale factor.

For example, 1280x960 / 1024x768 = 1.25. Adjusting every Sprite's size by 25% would probably work?

Am I missing something embarrassingly simple here?

I code, I throw a shrimp on the barbie. I am content.

Attachments

Login to view attachments
Hawkblood
14
Years of Service
User Offline
Joined: 5th Dec 2009
Location:
Posted: 27th Apr 2011 06:45
You would need to scale the sprites' u&v scales seperately because some resolutions have different aspect ratios. You have the right idea though.....

The fastest code is the code never written.
DarthJim
13
Years of Service
User Offline
Joined: 26th Dec 2010
Location: Australia
Posted: 27th Apr 2011 10:59
Yeah, separate uv factors for sure.

Still, it seems like a reasonable amount of work for something I thought might be relatively simple ( I'm not really against building something useful from scratch to solve a problem, but not if more experienced folk have already solved it! ).

I would imagine I'd either need to scale all sprites as they are reloaded ( after the resolution change removes them ) or automatically scale as part of the my standard Sprite load procedure.

I haven't tested yet, but I would also presume that their positioning may be affected, I wonder if a Sprite loaded at say (50, 50) at 1024x768 would be in the same relative position in the window as with 1600x1200? I could apply a similar technique to the scale with a position offset, but again seems like I'm over thinking this

The manual re-size of the Window seems to be what I'm after, I might look into how this is done with DirectX. In the meantime if anyone has any thoughts.......

I code, I throw a shrimp on the barbie. I am content.
Hawkblood
14
Years of Service
User Offline
Joined: 5th Dec 2009
Location:
Posted: 27th Apr 2011 15:35
As far as the positioning, yes, you would have to do a ratio as well.

I would start with figuring out how to determine the actual size of the view and then make a width percent and a height percent variable. Set your initial view size to whatever (1024x768) and use math to determine the W% & H% of the new size when it changes. Use the %'s to scale the sprites and when you dbPasteSprite(), use the %'s as a multiplier for the position.....

The first trick is to determine when the view size is changed. I'm not at my home pc now, but I'm sure there's some way to do this either as a DGDK function, Windows function, or DX function. Good luck.

The fastest code is the code never written.

Login to post a reply

Server time is: 2024-10-02 17:30:09
Your offset time is: 2024-10-02 17:30:09