Register
I was wondering if there is any easy way to change the "scale" of the graphics in my game? By this I mean, is there any simple code I can use to make a character appear double their normal size? (in which a 1x1 pixel is blown up to the size of 2x2 pixels) I would think this would somehow require my code to scan across my graphics and redraw the graphics from a center reference origin...
Secondly, a related question. Is there any way to alter how many tiles appear on screen during gameplay? By this I mean, CUSTOM usually displays 10 tiles high and 16 tiles across. Could I somehow make it so my game displays 20 tiles high and 32 tiles across?
This is not something I require to make my current game, rather something I see as useful for future experimentation. I'm not sure how hard this type of feature would be to implement, but I'd sure love to see something like this become a built-in feature in the future. I think this would be especially useful for puzzle/maze related games, as it would allow the player to see a greater distance and thus offer more clues or suggestions to the players decision making process.
Also if you're having trouble understanding what I'm getting at, just ask and I'll attempt to explain this concept a bit more...
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
This is a strange question, I'll explain as best I can...
Mon Mar 10, 2014 3:12 pm 
Re: This is a strange question, I'll explain as best I can..
Mon Mar 10, 2014 3:32 pm
sheamkennedy wrote:
I was wondering if there is any easy way to change the "scale" of the graphics in my game? By this I mean, is there any simple code I can use to make a character appear double their normal size? (in which a 1x1 pixel is blown up to the size of 2x2 pixels) I would think this would somehow require my code to scan across my graphics and redraw the graphics from a center reference origin...
There is not currently any way to do this, although a "scale" feature for sprite slices could be a possibility at some point in the future.
sheamkennedy wrote:
Secondly, a related question. Is there any way to alter how many tiles appear on screen during gameplay? By this I mean, CUSTOM usually displays 10 tiles high and 16 tiles across. Could I somehow make it so my game displays 20 tiles high and 32 tiles across?
This is not something I require to make my current game, rather something I see as useful for future experimentation. I'm not sure how hard this type of feature would be to implement, but I'd sure love to see something like this become a built-in feature in the future. I think this would be especially useful for puzzle/maze related games, as it would allow the player to see a greater distance and thus offer more clues or suggestions to the players decision making process.
Secondly, a related question. Is there any way to alter how many tiles appear on screen during gameplay? By this I mean, CUSTOM usually displays 10 tiles high and 16 tiles across. Could I somehow make it so my game displays 20 tiles high and 32 tiles across?
This is not something I require to make my current game, rather something I see as useful for future experimentation. I'm not sure how hard this type of feature would be to implement, but I'd sure love to see something like this become a built-in feature in the future. I think this would be especially useful for puzzle/maze related games, as it would allow the player to see a greater distance and thus offer more clues or suggestions to the players decision making process.
Yes, there is an experimental feature that allows this, TMC and Master K used it in their game Carcere Vicis.
Re: This is a strange question, I'll explain as best I can..
Mon Mar 10, 2014 4:24 pm
Bob the Hamster wrote:
Yes, there is an experimental feature that allows this, TMC and Master K used it in their game Carcere Vicis.
Yes, there is an experimental feature that allows this, TMC and Master K used it in their game Carcere Vicis.
Awesome, I guess I'll just wait and see if one of them replies to this post. Otherwise I'll PM them for an explanation.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Mon Mar 10, 2014 8:09 pm
Well, I can tell you how to test it.
You need to go into the hidden menu for experimental features. Definitely make a backup copy of your rpg file first, because there are things in here that might screw up your game (this is the menu that for stuff we don't even trust as "nightly" features)
From the main menu, type the magic word
spam
Then go down to "Resolution Menu" and choose a new width and height. 0 and 0 means that the resolution will be the default size, 320x200. If you want to double the number of tiles displayed, use width:640 height:400
When you test your game, you will notice right away that some things don't work right. Most (maybe all?) menus will not fill up the whole screen. You also might see problems with maps that are smaller than the number of tiles that fills a screen, and I think there are some problems with wraparound maps.
But in spite of all those problems, it should at least give you an idea of what the feature will look like when it is ready.
You need to go into the hidden menu for experimental features. Definitely make a backup copy of your rpg file first, because there are things in here that might screw up your game (this is the menu that for stuff we don't even trust as "nightly" features)
From the main menu, type the magic word
spam
Then go down to "Resolution Menu" and choose a new width and height. 0 and 0 means that the resolution will be the default size, 320x200. If you want to double the number of tiles displayed, use width:640 height:400
When you test your game, you will notice right away that some things don't work right. Most (maybe all?) menus will not fill up the whole screen. You also might see problems with maps that are smaller than the number of tiles that fills a screen, and I think there are some problems with wraparound maps.
But in spite of all those problems, it should at least give you an idea of what the feature will look like when it is ready.
Tue Mar 11, 2014 3:03 am
Of course doubling the resolution does not scale anything, unless you reduce the zoom of the window to compensate.
Scaling slices including sprites and maps is something I would like to do, but considering how few people would actually make use of it it's got to be given a very low priority. Scaling just sprite slices would be a lot simpler so there's a reasonable chance of that being added. One thing that concerns me is that our scaled sprite drawing code is very slow.
Also the camera doesn't stop at the map edge on maps set to crop; backdrops are only 320x200; textboxes appear at the top left; and battles aren't updated either.
Scaling slices including sprites and maps is something I would like to do, but considering how few people would actually make use of it it's got to be given a very low priority. Scaling just sprite slices would be a lot simpler so there's a reasonable chance of that being added. One thing that concerns me is that our scaled sprite drawing code is very slow.
Quote:
When you test your game, you will notice right away that some things don't work right. Most (maybe all?) menus will not fill up the whole screen. You also might see problems with maps that are smaller than the number of tiles that fills a screen, and I think there are some problems with wraparound maps.
Also the camera doesn't stop at the map edge on maps set to crop; backdrops are only 320x200; textboxes appear at the top left; and battles aren't updated either.
Tue Mar 11, 2014 3:37 am
TMC wrote:
Of course doubling the resolution does not scale anything, unless you reduce the zoom of the window to compensate.
Scaling slices including sprites and maps is something I would like to do, but considering how few people would actually make use of it it's got to be given a very low priority. Scaling just sprite slices would be a lot simpler so there's a reasonable chance of that being added. One thing that concerns me is that our scaled sprite drawing code is very slow.
Also the camera doesn't stop at the map edge on maps set to crop; backdrops are only 320x200; textboxes appear at the top left; and battles aren't updated either.
Scaling slices including sprites and maps is something I would like to do, but considering how few people would actually make use of it it's got to be given a very low priority. Scaling just sprite slices would be a lot simpler so there's a reasonable chance of that being added. One thing that concerns me is that our scaled sprite drawing code is very slow.
Quote:
When you test your game, you will notice right away that some things don't work right. Most (maybe all?) menus will not fill up the whole screen. You also might see problems with maps that are smaller than the number of tiles that fills a screen, and I think there are some problems with wraparound maps.
Also the camera doesn't stop at the map edge on maps set to crop; backdrops are only 320x200; textboxes appear at the top left; and battles aren't updated either.
I tried it out and notice the map edge thing you speak of. This seems easy enough to work around.
I'm not too concerned with the sprite scaling, though I really love controlling the resolution.
Will this resolution feature ever support battling and text box placement? If this is not a very in-demand feature, is there any available plotscripting functions I can use to alter the resolution during my gameplay? I figure if a plotscripting function is available then I can simply use the default resolution for battling and speech, then call a script to change to 2x resolution for things like gameplay or puzzles.
Thanks.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Tue Mar 11, 2014 6:16 am
I hope that customisable resolution will be a stable feature in the next release, whenever that is.
We weren't planning to add script commands to change the resolution, though I think it could be a good idea to add in option to enable running your game at multiple resolutions to support different screen sizes and aspect ratios. (One reason I decided on the strange 480x300 resolution for Carcere Vicis is that at 2x zoom it can be played both on a normal 1280x1024 monitor and full screen on my netbook with black bars around the sides, while most other resolutions can't) But that's a different thing, and not a plan yet.
Textbox placement will get fixed, of course; that's easy. Larger textboxes which can make use of extra space will be a major project.
I'd like to add variable-size backdrops hopefully for the next version, as that shouldn't be too much work and will fix a major problem with higher (or lower) resolutions.
If the in-battle UI is replaced with slice collections and larger backdrops are supported then that should fix half the problem, while the enemy and hero positions could be updated without much trouble, I think...
It sounds like what you really want is 10x10 tiles.
We weren't planning to add script commands to change the resolution, though I think it could be a good idea to add in option to enable running your game at multiple resolutions to support different screen sizes and aspect ratios. (One reason I decided on the strange 480x300 resolution for Carcere Vicis is that at 2x zoom it can be played both on a normal 1280x1024 monitor and full screen on my netbook with black bars around the sides, while most other resolutions can't) But that's a different thing, and not a plan yet.
Textbox placement will get fixed, of course; that's easy. Larger textboxes which can make use of extra space will be a major project.
I'd like to add variable-size backdrops hopefully for the next version, as that shouldn't be too much work and will fix a major problem with higher (or lower) resolutions.
If the in-battle UI is replaced with slice collections and larger backdrops are supported then that should fix half the problem, while the enemy and hero positions could be updated without much trouble, I think...
It sounds like what you really want is 10x10 tiles.
Tue Mar 11, 2014 6:44 am
TMC wrote:
I hope that customisable resolution will be a stable feature in the next release, whenever that is.
We weren't planning to add script commands to change the resolution, though I think it could be a good idea to add in option to enable running your game at multiple resolutions to support different screen sizes and aspect ratios. (One reason I decided on the strange 480x300 resolution for Carcere Vicis is that at 2x zoom it can be played both on a normal 1280x1024 monitor and full screen on my netbook with black bars around the sides, while most other resolutions can't) But that's a different thing, and not a plan yet.
Textbox placement will get fixed, of course; that's easy. Larger textboxes which can make use of extra space will be a major project.
I'd like to add variable-size backdrops hopefully for the next version, as that shouldn't be too much work and will fix a major problem with higher (or lower) resolutions.
If the in-battle UI is replaced with slice collections and larger backdrops are supported then that should fix half the problem, while the enemy and hero positions could be updated without much trouble, I think...
It sounds like what you really want is 10x10 tiles.
We weren't planning to add script commands to change the resolution, though I think it could be a good idea to add in option to enable running your game at multiple resolutions to support different screen sizes and aspect ratios. (One reason I decided on the strange 480x300 resolution for Carcere Vicis is that at 2x zoom it can be played both on a normal 1280x1024 monitor and full screen on my netbook with black bars around the sides, while most other resolutions can't) But that's a different thing, and not a plan yet.
Textbox placement will get fixed, of course; that's easy. Larger textboxes which can make use of extra space will be a major project.
I'd like to add variable-size backdrops hopefully for the next version, as that shouldn't be too much work and will fix a major problem with higher (or lower) resolutions.
If the in-battle UI is replaced with slice collections and larger backdrops are supported then that should fix half the problem, while the enemy and hero positions could be updated without much trouble, I think...
It sounds like what you really want is 10x10 tiles.
This all sounds like wonderful new to me. It's so weird that every time I have a question about the editor, it seems that someone is already working on creating those features.
10 x 10 tiles would be neat, though I do like the amount of detail my game currently has with in the 20 x 20 tiles. I notice that changing the resolution naturally changes the size of the window the game is being played in. Would making my game playable at a resolution other than default forfeit me from later releasing said game to things like OUYA or stuff like that?
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Tue Mar 11, 2014 7:28 am
AFAIK 640x480 is quite close to the native resolution of non-HD televisions (though televisions aren't like computer monitors and it's all terribly complicated). Based on Google's dashboard it seems that a resolution of 640x480 is more than what about 22% of Android users (which includes tablets) have; though I'm a little suspicious of these numbers. But even if you tried to run it on a phone with a smaller resolution, it should scale it down to fit, just as it scales 320x200 up to fit. Which means only text would be a worry.
Also, the reason we have a cap of 640x480 is that the engine currently runs at 2x zoom by default instead of intelligently choosing the zoom.
Also, the reason we have a cap of 640x480 is that the engine currently runs at 2x zoom by default instead of intelligently choosing the zoom.
Tue Mar 11, 2014 3:05 pm
TMC wrote:
AFAIK 640x480 is quite close to the native resolution of non-HD televisions (though televisions aren't like computer monitors and it's all terribly complicated). Based on Google's dashboard it seems that a resolution of 640x480 is more than what about 22% of Android users (which includes tablets) have; though I'm a little suspicious of these numbers. But even if you tried to run it on a phone with a smaller resolution, it should scale it down to fit, just as it scales 320x200 up to fit. Which means only text would be a worry.
Also, the reason we have a cap of 640x480 is that the engine currently runs at 2x zoom by default instead of intelligently choosing the zoom.
Also, the reason we have a cap of 640x480 is that the engine currently runs at 2x zoom by default instead of intelligently choosing the zoom.
Alright. What is the reason for the text not scaling down when running on phones? Would text scaling ever become a feature of the engine? I'm assuming this is related to slice scaling which you already mentioned isn't in demand by users. If I were to choose this 640x480 resolution for my game, is there some sort of workaround you could suggest which would help me avoid this text scaling issue from arising in the future?
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Wed Mar 12, 2014 7:40 am
It's not a future issue. If your game's resolution is 640x480 and it gets scaled down to run on a device that has a 320x240 screen, then everything is scaled by 50%.
In the future you'll be able to use font at sizes other than fixed width 8x8. I can be pretty confident in saying that because it's nearly finished and has been so for years. Scaling text slices on the other hand is unlikely to happen.
50% scaling might be a bit much, but I think the default font (since it's quite blocky) would still be readable if scaled down 33% from 640x480 to 480x320, which I think is a popular resolution on cell phones.
In the future you'll be able to use font at sizes other than fixed width 8x8. I can be pretty confident in saying that because it's nearly finished and has been so for years. Scaling text slices on the other hand is unlikely to happen.
50% scaling might be a bit much, but I think the default font (since it's quite blocky) would still be readable if scaled down 33% from 640x480 to 480x320, which I think is a popular resolution on cell phones.
Wed Mar 12, 2014 1:15 pm
Alright thanks. I think that answers all my questions for the time being.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Sun Mar 16, 2014 5:35 pm
TMC wrote:
Also the camera doesn't stop at the map edge on maps set to crop; backdrops are only 320x200; textboxes appear at the top left; and battles aren't updated either.
Also the camera doesn't stop at the map edge on maps set to crop; backdrops are only 320x200; textboxes appear at the top left; and battles aren't updated either.
So... if my game isn't using textboxes (only slices) or the in-game battle system, I should be basically completely fine to use this feature effectively as long as I make cropped maps just a little wider/taller for extra space?
Quote:
If the in-battle UI is replaced with slice collections and larger backdrops are supported then that should fix half the problem, while the enemy and hero positions could be updated without much trouble, I think...
I have also wanted to see this for quite some time. The fact that it means possible variable screen sizes is even cooler.
Sun Mar 16, 2014 5:47 pm
Mystic wrote:
So... if my game isn't using textboxes (only slices) or the in-game battle system, I should be basically completely fine to use this feature effectively as long as I make cropped maps just a little wider/taller for extra space?
Well as Bob mentioned it is an experimental feature, so backing up your game is a must. As far as I can see it won't be a problem. Even in my game which will have textboxes, I think I'll do custom textboxes as large background slices that take up the full screen. That way when they appear in the game they will occupy the top left quadrant of the screen which I don't mind.
I do hope to see the battle system getting updated to support this though. My games far from being complete so I'm not too worried. Also I may consider making a custom battle system, I just don't want to have to deal with the endless testing and fixing that comes along with it.
⊕ P E R S O N A L M U S I C: https://open.spotify.com/album/6fEo3fCm5C3XhtFRflfANr
⍠ C O L L A B M U S I C: https://dustpuppets.bandcamp.com/releases
Mon Mar 17, 2014 8:23 am
I'm so sick of hearing about these trivial textbox and cropped map bugs! So I fixed them just to prove how trivial and unimportant they were. Unfortunately once I'd done that I started fixing various other, non-trivial, problems too. Maps smaller than the screen are now fully supported (unless you want to set it to wrap and see multiple copies of everything like a mirror maze) and I fixed that annoying flickering when walking over the map edge too.