Center Windows XP Edition
By Kyonides
Difficulty Level: Intermediate
Introduction
The sole purpose of this tutorial is to show you how easily you can center any kind of windows at will.
Even so a few basic features will be reviewed quickly to remind you of some important and unavoidable aspects of creating or modifying anything on a game scene.
Planned Stages
1 - Introductory Stage
- Display Windows
- Unfreeze / Freeze Pictures
- Create a Loop
- Update Method
2 - Window Creation
- Basic Window’s Elements
- Passing Parameters
- Creating Bitmaps & Strings
- Drawing Bitmaps & Strings
3 - Alter Windows
- Modularity & Encapsulation
- Relocate Windows
- Improve Modularity by Creating Reusable Code
- Center Windows
Introductory Stage
Optional Depending on Your End Goal
Note: You may not need to go through this stage if you’re just planning to modify a default script.
Step 1- To properly Display Windows we need a scene.
Summary
The engine has plenty of them but a brand new one will let you concentrate on our new windows only.
Here’s the barebones of our new scene:
class Scene_Test
end
Following the ancient RM class naming conventions, our scene is called Scene_Test.
class lets us create a brand new object that can be copied multiple times.
Why is this important?
Well, without that we could be forced to draw the last state of that very same scene only instead of getting a fresh scene on demand.
You wouldn’t like to only open the inventory or the equip menu every single time you hit the Cancel button right?
You want some options to show up instead. Then a class is what you need here.
Now that we got one, what do we do next?
Step 2 - Unfreeze / Freeze all pictures on screen.
Summary
class Scene_Test
def main
Graphics.transition
# some code here
Graphics.freeze
end
end
def means we are defining a method that will belong to our custom scene class from now on.
There we defined the main method. This is a method that all scenes need in order to be able to keep playing our game. The lack of this method would quickly throw an error in our faces here.
We need to call the transition and freeze methods defined in the Graphics module to be able to create a seamless transition between the previous scene, our scene and the next one. This is mandatory.
Usually, this means leaving the map, opening our scene, and then going back to the current map.
Step 3 - Create a loop for this new scene.
Summary
class Scene_Test
def main
Graphics.transition
loop do
Graphics.update
Input.update
update
break if $scene != self
end
Graphics.freeze
end
end
Why do we create a loop?
That’s because we need to stay in our current scene. Otherwise, it’d go back to the map. It’s highly likely that you’d just notice that the map events stopped moving briefly and that would be all.
To keep our scene running smoothly, we need to update 2 things:
- Graphics
- Input
If we don’t refresh our graphics, the maker will soon tell us that it got stuck.
Not updating the input function would render our new scene completely useless UNLESS we never intended to make it interactive.
Note: Usually, transitional scenes don’t need any input at all. Instead they’d depend on a timer.
We also need to break that loop or will never be able to return to our map or any other scene you can think off. self stands for the current scene (a custom Ruby class) we’re working on.
Note: So far we can’t see anything on screen… except for an error message telling us that there’s no update method.
Step 4 - Adding an update method.
Summary
class Scene_Test
def main
Graphics.transition
loop do
Graphics.update
Input.update
update
break if $scene != self
end
Graphics.freeze
end
def update
if Input.trigger?(Input::B)
$game_system.se_play($data_system.cancel_se)
$scene = Scene_Map.new
return
end
end
end
Now that the update method does exist, we can leave our empty scene and return to the map.
Input.trigger? allows us to ask if the player has pressed a button, the Cancel button in this case, and released it. That’s triggering a button. In all RGSS-based engines those buttons are represented by CONSTANTS like A, B, C, SHIFT and others. All of them are part of the Input module. The reference :: operator makes the connection for us.
The $game_system.se_play($data_system.cancel_se) method call is the long way RMXP relies upon to make any SE play in game. In this particular case it plays the Cancel SE.
$game_system is our running copy of the Game_System class.
se_play is one of its methods. It does play SE.
$data_system is a copy of the System tab’s contents already loaded into memory.
cancel_se stands for the Cancel SE variable we once picked in the System tab.
If we had never added such a if statement, our condition, we wouldn’t be able to ever get out of our test scene. :o
You don’t want to shut down your game by brute force, do you? ![]()
return stands for returning to the method that originally called it. In this case it’s the loop found inside the main method.
Note: Keep in mind that right now we can only watch a big black nothing on screen. ![]()
In my next chapter I’ll start dealing with defining the actual windows.