Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
Profile
Locker
Play ListsPEPSIOTAKU'S PROFILE
Close
Search
Filter
All
Game Pages
User Statuses
What size IS full screen - Debate
Oooh, I love this stuff.
Technical crap for those that want to understand this topic at a granular level:
(Taken from the 2nd image, the nicer of the two)
Bickering aside, as one can see, the the scaled pixels alternate between 5x5, 5x6, 6x6 and 6x5 when that image is scaled up to 1320x880. It looks okay to the untrained eye, and it's kind of annoying to the folks who notice it, but what they're noticing is pixel scaling. With that said, there's not a whole lot you can control about it. Period. That's kind of how you have to look at it, because it depends completely the display resolution of the physical monitor itself and what it's capabilities are. It's an unknown variable.
With portable consoles, pixel scaling is always 1:1 because the screens are still relatively small enough that they don't require scaling. What you absolutely can control is the aspect ratio, which is what Jude was talking about. If you are developing from the ground up, you can take aspect ratio into account to figure out your desired scaling preference. JS is right in that by picking the right resolution that works for your game, you can minimize undesirable pixel scaling while still maximizing common screen ratios.
For instance, GBA games are 240x160, which is a 3:2 ratio, nonstandard for PCs... so scaling that up to 1920 width (800%) would require a height of 1280 (higher than 16:10's 1200px, and 16:9's 1080px). Let's say you had a 16:10 monitor. In order to see the whole picture in the correct aspect ratio, you have to scale it to the height of 1200, making the width 1800 (750%). 1800x1200 isn't a standard windows resolution, so, it has to use 1920x1200, but pads it with black bars on the left & right (pillarboxing) to retain that aspect ratio. If you absolutely had to have 1:1 pixel scaling, the closest you could get in that case would be 1680x1120 (700%), where you'd end up with both pillarboxing and letterboxing (top/bottom) in a 1920x1200 display resolution.
SNES emulation has the same problem. The console itself was 256x224, which does not scale up cleanly to a resolution such as 1920x1200 or 1920x1080, so you end up with black bars all around the image. If you were to scale it to the height of that 16:10 screen, you'd only have pillarboxing, but the pixels would be scaled by something like 535% and get that alternating pattern effect of distorted pixels. This looked gnarly back in the day when people had screens that were 800x600, but it's not so bad these days with much higher resolutions.
RM Specific:
This ties a little into what JS was saying about choosing "640 x 352 which is the closest to 640x360 (16:9) that still supports whole tiles." This is actually a great topic in and of itself, because choosing the resolution in tile-based games impacts whether you can display the character in the direct center of the screen (VX Ace) vs. off to the side (2k/3/XP) In 2k3, the screen of course was 320x240, and always showed 20x15 tiles when the character wasn't moving (offset by x pixels when moving). If the character (while still) was centered on the screen, you'd see half of one tile on the far right and half of another tile on the far left, so to combat this, the character was displayed off-center (in 1 of the 4 center tiles). VX chose the 544x416 resolution so that the player could be dead center on the screen and not cut off tiles along the edges. It still displayed at 640x480 resolution, resulting in pillarboxing and letterboxing because Enterbrain didn't want to scale up the image and end up with uneven pixel scaling.
640x352 could work in that it would have 4 pixels of letterboxing on the top and bottom (scaled up to whatever 16x9 display you have).
TL;DR:
The maximum resolution of the display is "full screen" as far as 2D games are concerned, but there are numerous considerations as to how you want your game to display, as outlined above. When you take out the output resolution as a factor, pixel scaling is no longer a concern, because it's not something you have control over.
Technical crap for those that want to understand this topic at a granular level:
(Taken from the 2nd image, the nicer of the two)
Bickering aside, as one can see, the the scaled pixels alternate between 5x5, 5x6, 6x6 and 6x5 when that image is scaled up to 1320x880. It looks okay to the untrained eye, and it's kind of annoying to the folks who notice it, but what they're noticing is pixel scaling. With that said, there's not a whole lot you can control about it. Period. That's kind of how you have to look at it, because it depends completely the display resolution of the physical monitor itself and what it's capabilities are. It's an unknown variable.
With portable consoles, pixel scaling is always 1:1 because the screens are still relatively small enough that they don't require scaling. What you absolutely can control is the aspect ratio, which is what Jude was talking about. If you are developing from the ground up, you can take aspect ratio into account to figure out your desired scaling preference. JS is right in that by picking the right resolution that works for your game, you can minimize undesirable pixel scaling while still maximizing common screen ratios.
For instance, GBA games are 240x160, which is a 3:2 ratio, nonstandard for PCs... so scaling that up to 1920 width (800%) would require a height of 1280 (higher than 16:10's 1200px, and 16:9's 1080px). Let's say you had a 16:10 monitor. In order to see the whole picture in the correct aspect ratio, you have to scale it to the height of 1200, making the width 1800 (750%). 1800x1200 isn't a standard windows resolution, so, it has to use 1920x1200, but pads it with black bars on the left & right (pillarboxing) to retain that aspect ratio. If you absolutely had to have 1:1 pixel scaling, the closest you could get in that case would be 1680x1120 (700%), where you'd end up with both pillarboxing and letterboxing (top/bottom) in a 1920x1200 display resolution.
SNES emulation has the same problem. The console itself was 256x224, which does not scale up cleanly to a resolution such as 1920x1200 or 1920x1080, so you end up with black bars all around the image. If you were to scale it to the height of that 16:10 screen, you'd only have pillarboxing, but the pixels would be scaled by something like 535% and get that alternating pattern effect of distorted pixels. This looked gnarly back in the day when people had screens that were 800x600, but it's not so bad these days with much higher resolutions.
RM Specific:
This ties a little into what JS was saying about choosing "640 x 352 which is the closest to 640x360 (16:9) that still supports whole tiles." This is actually a great topic in and of itself, because choosing the resolution in tile-based games impacts whether you can display the character in the direct center of the screen (VX Ace) vs. off to the side (2k/3/XP) In 2k3, the screen of course was 320x240, and always showed 20x15 tiles when the character wasn't moving (offset by x pixels when moving). If the character (while still) was centered on the screen, you'd see half of one tile on the far right and half of another tile on the far left, so to combat this, the character was displayed off-center (in 1 of the 4 center tiles). VX chose the 544x416 resolution so that the player could be dead center on the screen and not cut off tiles along the edges. It still displayed at 640x480 resolution, resulting in pillarboxing and letterboxing because Enterbrain didn't want to scale up the image and end up with uneven pixel scaling.
640x352 could work in that it would have 4 pixels of letterboxing on the top and bottom (scaled up to whatever 16x9 display you have).
TL;DR:
The maximum resolution of the display is "full screen" as far as 2D games are concerned, but there are numerous considerations as to how you want your game to display, as outlined above. When you take out the output resolution as a factor, pixel scaling is no longer a concern, because it's not something you have control over.
[RM2K]Help with opening protected rm2k games
I mean, the point of encrypting games is to not be able to poke around at the resources... but it's inevitable that somebody out there has the knowledge/skill to do it (Cherry) and I totally understand the curiosity behind wanting to.
Personally, I only have a loose understanding of how they work. Each file's data is probably stacked together into one file, probably including the headers, which get parsed out into memory somehow so that the core RPG_RT.exe won't trigger data reading errors, so in theory if you could find the headers of each resource file, you could parse them out yourself. With actual encryption brought into that mix, it's a different story because there's not much you can do without the encryption key, however, even that would have to be stored by Molebox somehow.
I had some conversation with Cherry ages ago and he seemed to think Molebox's encryption wasn't a big deal, and that you could still get around it. I have no idea if that's the case with Enigma Virtual Box (my previous post), or not. From a compatibility standpoint, Enigma does the best packing job, so it might be more advanced... or not. I'm speculating, so who knows!
Personally, I only have a loose understanding of how they work. Each file's data is probably stacked together into one file, probably including the headers, which get parsed out into memory somehow so that the core RPG_RT.exe won't trigger data reading errors, so in theory if you could find the headers of each resource file, you could parse them out yourself. With actual encryption brought into that mix, it's a different story because there's not much you can do without the encryption key, however, even that would have to be stored by Molebox somehow.
I had some conversation with Cherry ages ago and he seemed to think Molebox's encryption wasn't a big deal, and that you could still get around it. I have no idea if that's the case with Enigma Virtual Box (my previous post), or not. From a compatibility standpoint, Enigma does the best packing job, so it might be more advanced... or not. I'm speculating, so who knows!
[RM2K]Help with opening protected rm2k games
author=iddalai
https://www.youtube.com/watch?v=EOQcnliEjXM
Cool post bro. That was my favorite part of Altered Beast too!! What a game.
[RM2K]Help with opening protected rm2k games
The tool you're probably thinking of is Molebox Pro. I found v2.2981 works the best, at least with 2k3... although it starts to get hairy with patches and things and sort of becomes unusable.
Another simpler option is EXEfusion by Houxtech (if you can find it), although all it does is extract all of the resources into a hidden directory while the game is open, and then gets rid of it all again when the game closes. In other words, very sloppy. Oh, and it has an ugly popup after you quit the game.
Since I use DynRPG in 2k3 and realized Molebox would no longer work, I did some digging (a LOT) last year or the year before and found Engima Virtual Box. I'd go so far as to call it the gold standard these days for that sort of thing, but I haven't tested 2k games (can't see why they wouldn't work). Enigma VB seems to do a much better jobs than Molebox ever did, and there's a ton more options and flexibility, basically allowing you to pick and choose which resources to pack, and how to pack them with no unexpected side effects or crashes. It works swimmingly and the best part of course is that it's free!
Another simpler option is EXEfusion by Houxtech (if you can find it), although all it does is extract all of the resources into a hidden directory while the game is open, and then gets rid of it all again when the game closes. In other words, very sloppy. Oh, and it has an ugly popup after you quit the game.
Since I use DynRPG in 2k3 and realized Molebox would no longer work, I did some digging (a LOT) last year or the year before and found Engima Virtual Box. I'd go so far as to call it the gold standard these days for that sort of thing, but I haven't tested 2k games (can't see why they wouldn't work). Enigma VB seems to do a much better jobs than Molebox ever did, and there's a ton more options and flexibility, basically allowing you to pick and choose which resources to pack, and how to pack them with no unexpected side effects or crashes. It works swimmingly and the best part of course is that it's free!
+++ DynRPG - The RM2k3 Plugin SDK +++
Hey all: Just as a quick heads up, I changed my website from www.rewtone.com to www.rewking.com (self-promotion/job search reason), so if anyone is still looking for dynrpg stuff, I edited all of the posts that used the old url from the past year or two to the new one.
http://www.rewking.com/dynrpg/
You might find a broken link here or there from quoted posts or whatever else, so sorry for the inconvenience! :<
http://www.rewking.com/dynrpg/
You might find a broken link here or there from quoted posts or whatever else, so sorry for the inconvenience! :<
[RM2K3] Setting up an the RNG
You more or less have the right idea. Start with this:
Set a variable from 0 to 100
Check the variable if it's above or below a certain point ( <= 30 would be 30%)
Then you can modify that as you see fit. A number from 0 to 1000 would be the equivalent of using a % with 1 decimal place, or 0 to 10 would be % increments of 10.
If you have to check more than 2, for instance: <= 30, <= 60, > 60, just make sure the conditional branches themselves are prioritized so that they all get checked. <=30 would have to get checked first, since the number "10" could be both <= 30 or <= 60.
Set a variable from 0 to 100
Check the variable if it's above or below a certain point ( <= 30 would be 30%)
Then you can modify that as you see fit. A number from 0 to 1000 would be the equivalent of using a % with 1 decimal place, or 0 to 10 would be % increments of 10.
If you have to check more than 2, for instance: <= 30, <= 60, > 60, just make sure the conditional branches themselves are prioritized so that they all get checked. <=30 would have to get checked first, since the number "10" could be both <= 30 or <= 60.
The official English 2k3 version is out!
Ugh this is just the worst thing to explain...
You're describing setting a variable to another variable though. That's not what it does. It set's a variable to the value of a variable defined by another variable's value (lol). Just do this in both official and unofficial 2k3:
... It's the behavior of an array index, because you're essentially doing this:
Maybe neither description is intuitive enough.
Edit: Slowbro
author=Liberty
No, what I meant is that I never saw it as not being assigned to the number of the actual variable in question - that is, it is relating to another variable number. The Variable ID is the number of the variable itself - you're picking to show that variable's input. It's a very simple concept to understand. You're basically making one variable INTO another variable - by picking the number of the variable (the ID of the variable) you want to substitute.
You're stealing that variable's 'identity' (ID). Variable 0001 is now (for all intents and purposes) Variable 0003.
You're describing setting a variable to another variable though. That's not what it does. It set's a variable to the value of a variable defined by another variable's value (lol). Just do this in both official and unofficial 2k3:
@>Control Variables: [0007] = 21
@>Control Variables: [0021] = 6
@>Control Variables: [0001] = Variable ID [0007]
@>Text: \V[1]
: : \V[7]
... It's the behavior of an array index, because you're essentially doing this:
a = b[b[7]]
a = b[21]
a = 6
Maybe neither description is intuitive enough.
Edit: Slowbro
Misaos Categories for 2016
The official English 2k3 version is out!
Yeah that's understandable... but I think the confusion is how the terminology is used. Using my previous example, if you chose V7 with a value of 21, "Variable ID" makes me think 21 could get returned rather than its value of 6, even though that's what the "Variable" option above it essentially does. Reference or index describes a level deeper to me I guess.
I see posts frequently about confusion or general uncertainty about variables, so the more intuitive, the better. Maybe the terminology change should be across all makers? ...Unless there would be riots. :(
I see posts frequently about confusion or general uncertainty about variables, so the more intuitive, the better. Maybe the terminology change should be across all makers? ...Unless there would be riots. :(
The official English 2k3 version is out!
I hate nitpicking but I just had a conversation with BadLuck about this, and it's maybe been brought up before, but we noticed 2 terminologies that should really be changed in the next version:
Both under "Control Variables"...
"Variable" within the "Variable" block isn't intuitive. It should be "Reference" because it's the referenced variable from another variable
Ex: If set to V0001, and V0001 is "3" then it's going to use V0003.
Next is "Variable ID" under Operand. Similar to the other one, it's more of a reference... but it's equal to the value stored from the index of the specified variable... so with the current terminology, if you do:
The text box will print:
6
21
The key point being that "6" gets passed from V21 to V1 by referencing V21 in V7.
Pirated 2k3 uses "Value Stored in Index" which makes much more sense IMO. Might be able to shorten it to "Variable Index", "Value in Index" or something, but "Variable ID" just doesn't make sense.
Both under "Control Variables"...
"Variable" within the "Variable" block isn't intuitive. It should be "Reference" because it's the referenced variable from another variable
Ex: If set to V0001, and V0001 is "3" then it's going to use V0003.
Next is "Variable ID" under Operand. Similar to the other one, it's more of a reference... but it's equal to the value stored from the index of the specified variable... so with the current terminology, if you do:
@>Control Variables: [0007] = 21
@>Control Variables: [0021] = 6
@>Control Variables: [0001] = Variable ID [0007]
@>Text: \V[1]
: : \V[7]
The text box will print:
6
21
The key point being that "6" gets passed from V21 to V1 by referencing V21 in V7.
Pirated 2k3 uses "Value Stored in Index" which makes much more sense IMO. Might be able to shorten it to "Variable Index", "Value in Index" or something, but "Variable ID" just doesn't make sense.
Games - Tester
Games - Other
