You can determine the available screen area with code.
I would then use this information to change the viewport to resize - ensuring available aspect ratio is kept.
If screen size is either bigger or smaller than your supported resize - you then scale when it hits max or min supported resolution - and because you resized the viewport with the correct aspect ratio - scale will work properly.
My website does both of these actions (modifies viewport, then scales if needed) - but doesn't currently leave the viewport in the correct aspect ratio - but I will add that bit of code in the next few days when I get some time as I think that will be a useful example.
(I want to make the game zones bigger - as I allow the viewport to increase in size up to 1920p resolution - but my original design was for 960 width... so on a big screen you can see the next game area straight away and I didn't want that).
1) spritesheet editors - try a few free ones - google search will reveal a bunch. add the word forum and you can find people talking about them. (e.g. spritesheet editor or spritesheet editor forum)
2) Sounds to me like you actually want to know how to load this into your game, so what you might want to look at instead in texture atlas support. You can also get texture atlas programs to help you create texture atlas files, you can then use this file in game - the file contains all the information required for each of the sprites/textures inside the image.
If you want to look into the above I would perform 2 searches:
a) Search to find if there are existing libraries / code for pygame that you can use to add texture atlas support.
b) If you don't find it - ignore texture atlas - not sure you want to code this yourself?
c) If you do find texture atlas support - then go search for a texture atlas creator - just use google again. :)
Texture atlas support is pre-built into some game makers. I haven't used pygame though.
It depends on the game and how much work you want to put in.
If your game is graphically intensive - perhaps 800x600 resolution and use scaling. If not - go with the maximum resolution you want to support as I believe scaling down will look better than up?
An alternative or addition: Can you expand/shrink your viewport (the amount of game scene you can see).
If your game won't support a variable viewport design - Unless it is a graphically intensive game - it is probably best to design for the largest resolution and then scale down as that will look better than scaling up. (but you may want to change some stuff dynamically based on size - e.g. text may get too small to read as it scales down)...
This test website link I put together as an experiment does the following:
resize the viewport between resolutions: 960x640 -> 1920x1024 (both the x and y can change independently as required) (I haven't properly designed the scene for 1920x1024 - but I will when I get time). Beyond these resolutions it scales either up or down. i.e. on a small mobile screen it will reduce the viewport to 960x640, then scale down to size.
here is the test link (note, I am currently re-writing the contact-us form keyboard class on this page so it doesn't work):
You can shrink this to a tiny size on the desktop browser and you can see it still works - but the text becomes unreadable etc. But with such a tiny size you can't do much about that. :)
The isometric example I have done (which I believe you have already seen) Uses Scaling only. It would have been perfect to use a dynamic viewport for this type of game... BUT that wasn't the point of the demo - lol. I believe the viewport in that example is fixed at 320x480 and uses scaling to fit keeping the aspect ratio...
What I don't have an example of (perhaps I should as part of the website) is dynamically modifying the viewport to ensure the resolution aspect is met - and then scale if needed.
The 5 images are: blood animation, goblin sprites, zombie sprites, grassland textures and 1 single collision texture image.
I have not released the code for sprite sheet support because I could not make it 'standard' (as I can't edit the GUI itself) - I modified the base javascript that is used to generate the game code.
Yeah I am not developing it for the demo - the demo is done and dusted.
I have spend the past few weeks doing learning projects - whilst doing so - some of the code can be kept and re-used as part of a library of code I am building up.
So I will put together the sprite sheet code and will even use the demo to test it - But the actual code I will release separately. (or not at all if the Tululoo community remains dead).
And no, Tululoo doesn't already support sprite sheets - pretty surprisingly because the GUI editor handles them fine to edit them, split them up and even rejoins them to export.
But not the javascript engine. :(
But I think I can fix that easily enough - and i'll put a variable at the top to make it easy to turn it on once the editor has generated your game files.
Did you do a refresh? I am using Chrome on both Desktop and Android phones. If I go back in history, then forward to the website again it uses a cached version - so is very quick.
But if you use the refresh button while on the page itself it gets a new version from the server.
I looked into both Texture Atlas and sprite sheets - for the stuff I want to do sprite sheets will be about as effective - I can cut down the image count to 3 (For the current version), where Texture Atlas could get it to 1.
I don't intend to make any super complex HTML5/Canvas games and implementing the sprite sheet looks so much easier, so I will just do that.
Yeah load times are ok, but quicker is better - and doing 300+ server requests to load 2 sets of sprite animations and textures is just slow and wasteful.
oh wait - are you only planning on supporting desktop (like) environments?
If this is the case - some of the concens above are minimised - e.g. more power is usually available on desktop like environments and if a keyboard is always attached, you don't have to worry about using a virtual keyboard api via CocoonJS etc.
Do it with some maths:
img dimensions = 1095 wide x 438 wide and is 15 sprites accross, and has 4 sprites down.
Therefore each sprite is: 1095/15 = 73px wide and 438/4 = 109px down.
So... If the sprite you want is in column X and column Y (the first sprite you want starts at 0)
The sprite maths you want for your () line above is:
( X*73, Y*109, (X*73)+73, (Y*109)+109 )
so if you want the very first sprite (top left) use X=0 and Y=0 in the above and you get the first sprite.
If you want the 5th sprite accross on the 3rd row down... X=5 and Y=3 and that is your sprite.
You can determine the available screen area with code.
I would then use this information to change the viewport to resize - ensuring available aspect ratio is kept.
If screen size is either bigger or smaller than your supported resize - you then scale when it hits max or min supported resolution - and because you resized the viewport with the correct aspect ratio - scale will work properly.
My website does both of these actions (modifies viewport, then scales if needed) - but doesn't currently leave the viewport in the correct aspect ratio - but I will add that bit of code in the next few days when I get some time as I think that will be a useful example.
(I want to make the game zones bigger - as I allow the viewport to increase in size up to 1920p resolution - but my original design was for 960 width... so on a big screen you can see the next game area straight away and I didn't want that).
I am not sure what you are after.
1) spritesheet editors - try a few free ones - google search will reveal a bunch. add the word forum and you can find people talking about them. (e.g. spritesheet editor or spritesheet editor forum)
2) Sounds to me like you actually want to know how to load this into your game, so what you might want to look at instead in texture atlas support. You can also get texture atlas programs to help you create texture atlas files, you can then use this file in game - the file contains all the information required for each of the sprites/textures inside the image.
If you want to look into the above I would perform 2 searches:
a) Search to find if there are existing libraries / code for pygame that you can use to add texture atlas support.
b) If you don't find it - ignore texture atlas - not sure you want to code this yourself?
c) If you do find texture atlas support - then go search for a texture atlas creator - just use google again. :)
Texture atlas support is pre-built into some game makers. I haven't used pygame though.
Looks good prozi - modifying the viewing area (e.g. viewport).
I just tried your last one at 480x320 on the desktop and I think it could also use both resize plus scaling.
i.e. you appear to be resizing the viewport to the available resolution = great.
But also fairly easy to do is to define limits to the viewable area and use % scaling beyond that.
Based on the example above I would have set the limit to no less than 640x480px.
Although the game is 'playable' at 480x320 - you don't see much more than just the player. :)
I am not an artist.
But I like them. So my answer is yes please. :)
Your art is pretty decent imo and may also serve as inspiration for someone to make additions/enhancements etc.
It depends on the game and how much work you want to put in.
If your game is graphically intensive - perhaps 800x600 resolution and use scaling. If not - go with the maximum resolution you want to support as I believe scaling down will look better than up?
An alternative or addition: Can you expand/shrink your viewport (the amount of game scene you can see).
If your game won't support a variable viewport design - Unless it is a graphically intensive game - it is probably best to design for the largest resolution and then scale down as that will look better than scaling up. (but you may want to change some stuff dynamically based on size - e.g. text may get too small to read as it scales down)...
This test website link I put together as an experiment does the following:
resize the viewport between resolutions: 960x640 -> 1920x1024 (both the x and y can change independently as required) (I haven't properly designed the scene for 1920x1024 - but I will when I get time). Beyond these resolutions it scales either up or down. i.e. on a small mobile screen it will reduce the viewport to 960x640, then scale down to size.
here is the test link (note, I am currently re-writing the contact-us form keyboard class on this page so it doesn't work):
http://itmatters.mobi/new_website_test/index.php (may break as I test things)
You can shrink this to a tiny size on the desktop browser and you can see it still works - but the text becomes unreadable etc. But with such a tiny size you can't do much about that. :)
The isometric example I have done (which I believe you have already seen) Uses Scaling only. It would have been perfect to use a dynamic viewport for this type of game... BUT that wasn't the point of the demo - lol. I believe the viewport in that example is fixed at 320x480 and uses scaling to fit keeping the aspect ratio...
What I don't have an example of (perhaps I should as part of the website) is dynamically modifying the viewport to ensure the resolution aspect is met - and then scale if needed.
Out of interest - I implemented sprit sheets as it was far easier to do so.
I made a copy of the demo so a comparison could be made before and after.
This version only needs to load 5 images (if I manually combined some of the files I could have reduced this further).
http://itmatters.mobi/demo/iso_ss/
The 5 images are: blood animation, goblin sprites, zombie sprites, grassland textures and 1 single collision texture image.
I have not released the code for sprite sheet support because I could not make it 'standard' (as I can't edit the GUI itself) - I modified the base javascript that is used to generate the game code.
Yeah I am not developing it for the demo - the demo is done and dusted.
I have spend the past few weeks doing learning projects - whilst doing so - some of the code can be kept and re-used as part of a library of code I am building up.
So I will put together the sprite sheet code and will even use the demo to test it - But the actual code I will release separately. (or not at all if the Tululoo community remains dead).
And no, Tululoo doesn't already support sprite sheets - pretty surprisingly because the GUI editor handles them fine to edit them, split them up and even rejoins them to export.
But not the javascript engine. :(
But I think I can fix that easily enough - and i'll put a variable at the top to make it easy to turn it on once the editor has generated your game files.
What browser? (and on desktop or mobile?)
Did you do a refresh? I am using Chrome on both Desktop and Android phones. If I go back in history, then forward to the website again it uses a cached version - so is very quick.
But if you use the refresh button while on the page itself it gets a new version from the server.
I looked into both Texture Atlas and sprite sheets - for the stuff I want to do sprite sheets will be about as effective - I can cut down the image count to 3 (For the current version), where Texture Atlas could get it to 1.
I don't intend to make any super complex HTML5/Canvas games and implementing the sprite sheet looks so much easier, so I will just do that.
Yeah load times are ok, but quicker is better - and doing 300+ server requests to load 2 sets of sprite animations and textures is just slow and wasteful.
oh wait - are you only planning on supporting desktop (like) environments?
If this is the case - some of the concens above are minimised - e.g. more power is usually available on desktop like environments and if a keyboard is always attached, you don't have to worry about using a virtual keyboard api via CocoonJS etc.
Pages