TFT's and Gaming

[T_M_C]

Another option, is a scalable window mode.

Let the user keep is favourite desktop res and let him scale the game window to suit.

I don't know if db pro allows this.

I have the same problem with my latest game, being 2d only and fixed at 1024 x 768 res.  Not having a tft monitor means i can't test at home either so will have to rely on other users feedback.

The best course of action that i'm trying to follow is to allow the user as many options as i can fit in.
Resolution, color depth, windowed / full screen ect.
Maximises your audience which translates into sales if your going comercial.

Blitzmax renders images to 3d planes which can be scaled in realtime.  I know db pro does this too, so render to an image / texture first seems a reasonable method to try.

I'll do some tests at home and see what i can come up with.

It's an issue i need to get resolved pretty soon.

TMC

[Lyx]

Those are all just temporary hacks, because the issue isn't limited to different DPI but also different aspect ratios. Widescreen displays are becoming more and more popular. A clean solution would of course be a game, which scales all its graphics anyways, stores OSD-elements as relative positions, and which doesn't rely on aspect ratios (at least not about sane ones - 2:10 aspect ratio is of course utter bullshit).

[fog]

Blitzmax renders images to 3d planes which can be scaled in realtime.  I know db pro does this too, so render to an image / texture first seems a reasonable method to try.

That's doable but it's too slow for older hardware so not an option for me.  I still make sure everything will run perfectly well on my old trusty P4 1.6 GeForce2 powered machine and rendering to an image certainly wouldn't.

Those are all just temporary hacks, because the issue isn't limited to different DPI but also different aspect ratios. Widescreen displays are becoming more and more popular. A clean solution would of course be a game, which scales all its graphics anyways, stores OSD-elements as relative positions, and which doesn't rely on aspect ratios (at least not about sane ones - 2:10 aspect ratio is of course utter bullshit).

Scaling graphics, if you're talking sprites as I use, looks really awful.  The only decent solution would be to have different images for each resolution and, as they aren't image intensive, that's the option I'm considering with my current puzzle games.


I use a widescreen TFT and, TBH, because my stuff is quite blurry anyway it doesn't look to bad to me (or certainly much different).  Obviously the widescreen distorts things slightly but again, unless I make a real point of looking for it, I can't even notice.  I will try and support widescreen in future but that does throw up a load of other issues that aren't just gfx related.

[Lyx]

I use a widescreen TFT and, TBH, because my stuff is quite blurry anyway it doesn't look to bad to me (or certainly much different).  Obviously the widescreen distorts things slightly but again, unless I make a real point of looking for it, I can't even notice.

That depends much on the genre of the game too. I.e. if we talk arena shooters with mouse-control, then the aspect-ratio distortion also applies to controls in a game which requires accuracy. In a puzzler on the other hand, i guess this typically isnt much of a problem.

A random idea: If an UI is solid (not like a HUD), then one may use it as an elegant trick, to adapt between widescreen and non-widescreen displays. For example, with a widescreen displays, one could place more UI elemends at the horizontal edges, while on non-widescreen displays, one could move them to the top or bottom. That way, it may be possible to upscale or downscale the playfield without the need for aspect-ratio adjustments. Of course, this idea is completely in conflict with reducing the amount of necessary static UI elements

[fog]

I use a widescreen TFT and, TBH, because my stuff is quite blurry anyway it doesn't look to bad to me (or certainly much different).  Obviously the widescreen distorts things slightly but again, unless I make a real point of looking for it, I can't even notice.

That depends much on the genre of the game too. I.e. if we talk arena shooters with mouse-control, then the aspect-ratio distortion also applies to controls in a game which requires accuracy. In a puzzler on the other hand, i guess this typically isnt much of a problem.

I have to admit that widescreen "stretching" isn't that apparent to me in the controls either....unless, as mentioned earlier, I make a point of looking for it.  I do though appreciate that might not be the case for everyone so it's good to get feedback if it's a major issue for some people.

A random idea: If an UI is solid (not like a HUD), then one may use it as an elegant trick, to adapt between widescreen and non-widescreen displays. For example, with a widescreen displays, one could place more UI elemends at the horizontal edges, while on non-widescreen displays, one could move them to the top or bottom. That way, it may be possible to upscale or downscale the playfield without the need for aspect-ratio adjustments. Of course, this idea is completely in conflict with reducing the amount of necessary static UI elements

The puzzle game I've been working on this evening kind of does something like that.  In this game the whole screen is covered by a grid with the HUD elements at the sides.  On the widescreen version I'm adding a couple of extra grid columns to fill the extra width and spacing the HUD elements out slightly.  Incidentally the full screen grid effect looks pretty cool....not as sure abou the gameplay yet

[Lyx]

Scaling graphics, if you're talking sprites as I use, looks really awful.

I'd like to get back to that comment. It may be true on current displays - and may stay true for the next 3-5 years..... but unless i'm missing something this issue will go away in the mid-term already, because DPI is going up like mad recently. The bottleneck no longer is the hardware, but instead the software. With this i mean, that currently people still stick to relatively low DPI Displays because of lack of scalability support in OS and apps. On the other hand, dirty tricks like cleartype obviously show that we're far away from optimal DPI. I'd say that in 6-10 years stuff like 300dpi displays wont be an utopia anymore. At such high DPI-capability, scaling shouldn't be much of a problem anymore.

Of course one may say, that this is all and well, but not a solution for the situation NOW. Thats true. On the other hand, there is the question of if one makes games for the near-term only - or if one wants to make "classics". It's no secret that there are a lot of retro-gamers in the indie-community - for a good reason. And with significant consequences: a different mentality of what one "expects" from a game.

I for example am no longer much interested in "play it for a week, then forget it"-games. The stuff which stays on my HDD for longer than 10-30mins is stuff which stays there for YEARS - stuff which gets put into redundant BACKUPS - stuff which i expect to possibly play once in a while even 8 years into the future or even longer. The difference between "collector-mentality" and "fun-mentality" gets blurry here. I play for fun, not because of hype, fandom or some weird symbolic values - yet at the same time i am basically building an archive of classics - past games as well as current ones. And i suppose i'm not the alone with this kind of mentality in the indie-scene. So, with an audience which values that, the question also arises for game-creators: "what" are they trying to create?

[T_M_C]

Interestig reading.

I've been running some tests which havn't really thrown up a solution.

I tried the render scene to an image and then draw scaled image to screen approach, but as Fog implied, it ran riduclously slow.  That was for a 1024 x 768 32 bit display.
It would have solved the problem, except for the fact the speed hit was enormous.

I can't find a way for blitzmax to create a scalable windows window to draw the graphics too, but only a fixed size one.
This i'm assuming would be ok for users who have their desktops at higher resolutions than my games 1024 x 768 default res.  Just means the players with wide screen and high screen resolutions would have to play the game in a window to maintain the correct aspect ratio.

And i always prefer full screen modes of play anyway.  Much more immersive.

The code could be rewritten to allow for relative scaled positions dependant on the current display resolution, but thats pretty messy and requires a big rewrite.  Would probably throw up alot of problems and glitches too.  I have had some experience using that technique, but not for a whole game.

I'm now basically of the opinion that it's a basic fault with the language itself.  Why doesn't the language allow the user to render to a backbuffer image / texture and then that image / texture drawn to the frontbuffer at a different scale if so desired to suit whatever resolution is used.  If this was a hardware based solution it would be a great one.

As far as i can work out, the front and backbuffers are of the same size.  But as we all know, everybody doesn't use the same resolution.

If a user has a resolution of say 1280 x 1024 and my game is running at 1024 x 768 full screen, then i'm assuming the displayed screen will be stretched due to the difference in the aspect ratios.

All thats needed is to be able to rescale the final frontbuffer displayed image.

I need to do some research to see if other max users have addressed the issue.

It's impratical to create different sets of graphics at different sizes to cater for different resolutions, especialy for my game which is very image heavy.

And theres also the issue of larger resolutions hitting the games performance on lower spec machines.  I think a 1024 x 768 is a decent compromise between resolution and performance.

TMC

[fog]

Yeah it sounds like you've run into the same problems and contemplated the same solutions as me Masked.  It sounds a really simple problem to overcome until you really look into it.

In all honesty, and again this is based on the feedback I have received so feel free to contradict me, most people aren't bothered about the lack of resolution options at all and there are more concerns over the lack of a widescreen option.  That's why I'm concentrating on just offering a widescreen option but otherwise fixing the res in future.

And of course most commercial games are 3D and they have none of the scaling issues that you get with 2D pixel based games and so can be displayed happily at any res with little effort at all.

[PaulCunningham]

The approach I took with Doppelganger was to force a widescreen play area no matter what the res.  If the player has a 4:3 display they get black borders at the top and bottom of the screen.  Now this obviously fits in well with a horizontal shooter and the fact that it's for the 360 as well made it a no brainer for me. 

The other thing I don't have to worry about is the actual resolution chosen - all my objects live in world space.  An object in doppelganger is always the same size - it just gets drawn with more pixels at higher resolutions (using the same graphics asset - pngs with mip-mapping).

Can you not use simple square 2d models and map the sprite textures onto those?

[T_M_C]

Well, the trouble for me, is that my game world can scroll around in any direction and is designed to fit on a 1024 x 768 screen.

I could allow the user to view more of the level if he has a higher resolution, but i wanted to avoid that because it means showing more onscreen graphics than normal and means level design has to take this into account.

I'm actually really suprised that the issue of different screen resolutions and ratio's hasn't been adressed by the language for 2d mode.  To me, it's blindingly obvious to allow a scaling transform from the backbuffer to the frontbuffer.  It makes sense from a coding point of view, allowing for a default backbuffer size and ratio and the transform being automatic when the flip occurs that swaps the backbuffer to the frontbuffer.
It's just that it's very slow' coding it manualy.  And when you consider blitzmax can chuck around thousands of sprites with realtime scaling, alpha and rotaion it seems to me to be a major oversight.

I could allow for full screen modes higher than 1024 x 768 and with the same aspect ratio and draw black borders around the screen to allow for the same area of view as standard 1024 mode and i can also use a 1024 window if the resolution and ratio are higher too, always showing a 1024 x 768 window, no matter what the desktop res. 

So i do have several options, it's just a bit frustrating from a coders point of view.

TMC

[fog]

The other thing I don't have to worry about is the actual resolution chosen - all my objects live in world space.  An object in doppelganger is always the same size - it just gets drawn with more pixels at higher resolutions (using the same graphics asset - pngs with mip-mapping).

Can you not use simple square 2d models and map the sprite textures onto those?

Yeah that's the big advantage of using 3D.  Everything just automatically scales to whatever res you want.  Not so simple using DBPro's 2D sprites though which is quite ironic given that it uses 3D planes for it's sprites anyway.

And yes, the obvious solution would be for me to use bill-boarding with 3D planes myself instead of relying on the built in sprite commands, but I tried that a while ago and DBPro was so slow at deleting 3D objects that it was impossible.  The alternative option was to have a bank of 3D planes in memory, don't delete them and just reuse them whenever necessary but again I ran into problems.  This time DBPro was slowing down when I had several hundred objects in memory regardless of what I did to them.

I might need to try again and see if they've solved that problem yet.

[PaulCunningham]

And yes, the obvious solution would be for me to use bill-boarding with 3D planes myself instead of relying on the built in sprite commands, but I tried that a while ago and DBPro was so slow at deleting 3D objects that it was impossible.  The alternative option was to have a bank of 3D planes in memory, don't delete them and just reuse them whenever necessary but again I ran into problems.  This time DBPro was slowing down when I had several hundred objects in memory regardless of what I did to them.

That's exactly what I do

Do you sort your sprites at all to minimise gfx card state changes?  Favouring the glowy look, I tend to use additive blending so I don't need to bother too much with the drawing order so simply sorting by texture gives me a nice little bit of extra speed.

[fog]

Do you sort your sprites at all to minimise gfx card state changes?  Favouring the glowy look, I tend to use additive blending so I don't need to bother too much with the drawing order so simply sorting by texture gives me a nice little bit of extra speed.

I sort them but for playability and not for maximum speed.  If you have a shit load on screen then it's essential things like bullets always appear in front of FX so that's how I define my draw order.