Discussion about a few things before the final engine

[Blizzard]

Alright, the engine is closer and closer to completion. There are a few small details that I want to discuss before that.

1. Resolution & Fullscreen Mode

RMXP allows you to change the fullscreen mode anytime and with scripts it can even change the game resolution on the fly. While the resolution change is possible in April and has been implemented in the Win32+DirectX implementations, it's not been implemented anywhere else. The change of fullscreen mode hasn't been implemented anywhere.
I'm really not up to implement that stuff in April, especially since we'd have to implement it somehow in every windowsystem and rendersystem so I propose that we screw it. Not resolution change and no fullscreen mode change while the game is running. The user can specify the game resolution and fullscreen mode in arc.cfg and the players can change the fullscreen mode there if they really don't want to play in fullscreen.

2. Audio Pitch

To be honest, it's a bit messy to implement this properly. DirectSound seems to have an integrated way of handling this, but I'm not sure about the other audiosystems (OpenAL and SDL). Do we really have to implement this? ._. I understand the usefulness and I know that many people rely on that, but I think it's really a useless feature. ._. In the worst case I can implement this for ARC Legacy and DirectSound only which means we won't release ARC Legacy's exe for any other platform.

3. Text squishing

As you know, RMXP squishes text that's wider than the given box. While it might be a useful feature, to implement it the same way as RMXP did is quite bothersome, because they have a few degrees of squishiness and then the text gets cut off anyway. I'm just for leaving it get cut off, screw RMXP.

4. MIDI support

I know that many people want the MIDI support and so on, but there is a problem. The DirectSound version shouldn't be too much of a problem, but I don't have the slightest idea how well things would work in OpenAL and SDL. What do you suggest we do?

5. Text Rendering

There are a few things with text rendering that you should know. Basically depending on the height of the render rectangle, the vertical position gets affected depending on which vertical alignment is being used. The main problem here is the position offset from the top. While in RMXP if you use a height of 16, the text gets cut off, in Atres depending on the vertical alignment the text will be positioned and cut off in a different way. Should I just add a hack in the code to more accurately simulate the way RMXP does it or should I try to find an alternative to circumvent the problem in a cleaner way? I don't mind adding a hack for this kind of thing, because the whole RGSS code is basically completely clean of hacks and it's not like this is some code that we will have to improve much or maintain in the future as the actual Zer0 Division Engine will be different.

[ForeverZer0]

1. That sounds fine. There really isn't any need to change resolution during runtime, and changing a value in a config file isn't hard. Personally I think it is a bit unprofessional looking having the resolution changing during a run.

2. Hmmm. I kinda think this is an important feature, but I really can't offer you any insight on doing it, you know far more than I do in this area. If we have to release ARC Legacy on Windows only in order to make a timely release because this isn't implemented, that's fine by me, but I don't think it should be given up on entirely. That will give us some more time to research and come up with a way to do it. I suppose it is possible to edit the audio in an external editor, but it would be really nice to avoid such things.

3. I completely agree. I hate the whole RMXP text squishing thing, and I don't think it should have ever been implemented in the first place. It does nothing more than try to cover up a design flaw by the game creator that they should have accounted for in the first place.

4. Same answer as number 2.

5. Hack away.

[Blizzard]

Not to take your single opinion as the final one, but this here would be some kind of remaining to-do list for me. :3

• implement MIDI support in XAL


• implement pitch for audio in XAL


• throw Errno::ENOENT without using eval() at several places


• test Bitmap::rb_textSize


• change Color::toAprilColor to take into account negative values


• implement font caching for atrestff


• fix problem with D3DX9 device reset after CTRL+ALT+Delete


• using "exit" crashes the game


• fix vertical draw_text offset


• implement -debug argument


• add script files as internally embedded resources


• implement -encryption- in C++


• recompile Ruby with zlib support

And obviously the 2 remaining tasks to implement color and tone modification of the Renderable rendering.

[Fantasist]

Um, is this topic just for the devs or am I allowed to say something?

If I can weigh in:

Spoiler: ShowHide

Switching from fullscreen to windowed mode is something I consider essential, but I can live without it.

and changing a value in a config file isn't hard.

In this regard, are you guys going to make or integrate into ARC a config tool like RMXP's F1?
If you decide not to, game makers can still simply create their own launcher app (like Batman Arkham Asylum and many others). All they have to do is change the contents of arc.cfg, so I guess that's OK.

[Ryex]

1) this seems like an acceptable solution as there are a few work arounds
    a) we provide access to the cfg file inside the game engine that way people could make cfg scripts that could edit the cfg and then restart the game. heck, that pretty simple ans we could probably provide an example of one.
    b) we provide a 'boot script' like system. where if the user provides a boot script the games runs that first and when it is done it drops the current render system and restarts it. in this way if the user provides a boot scripts they could put the fullscreen ask script there / a change resolution option have it temp set the cfg in memory (we would need to provide access to that) and when the the render system restarts it uses the cfg from memory and starts it in the new resolution and or fullscreen mode.

personally I think the boot script system is brilliance we would just have to mark a flag on a script (perhaps in a scripts.arc file that contains information on scripts?) to mark it as the 'boot script', this script would probably need to be at the top of the script order. if the flag wasn't found it would skip the 'boot script'. thoughts on the idea?

2) personally I think it's a needed system. pyglet has it implemented in direct sound and OpenAL but does not use SDL so you can look at it's media module to see how the calls work if that helps. in any case I think it's a needed feature. as for SDL I found this user list conversation real quick where they suggest using OpenAL and even gives an example of how it's done in OpenAL. it even talks about how SDL converts midi's to wavs before playing them. http://lists.libsdl.org/pipermail/sdl-libsdl.org/2007-August/062166.html

3) screw it, kick it to the curb

4) I personally think it's an important feature. I believe CSound may be our best option for playing them / figuring out how to play them. it's cross platform.
http://sourceforge.net/projects/csound/
and here is a topic i found on playing midi through csound
http://csound.1045644.n5.nabble.com/How-to-play-MIDI-files-with-CSound-td1115983.html

5) I personally don't really care if you want to add the hack to the legacy version that fine but it's also fine to leave it as is I think.

[Blizzard]

Um, is this topic just for the devs or am I allowed to say something?

Of course, that's why it is in a public section.

In this regard, are you guys going to make or integrate into ARC a config tool like RMXP's F1?
If you decide not to, game makers can still simply create their own launcher app (like Batman Arkham Asylum and many others). All they have to do is change the contents of arc.cfg, so I guess that's OK.

It's actually a simple file like Game.ini, except that it offers a lot more options. I think of putting all game specific systematic options that you don't need a script for in there.

@Ryex:

1. I'm actually a bit ahead of you on that one. While you CAN specify different things in arc.cfg, there are default values integrated into the engine. So if there is no arc.cfg, the default values will be used.
But I don't think we have to overdo it. If somebody wants a boot script like that, they should make it themselves. There is no real need for that as we have to consider that the majority of users will not touch the scripts except for inserting or removing other people's scripts. Remember, we are making an RPG Maker for people who don't use scripts. The rest will get their bonus stuff, too, but this is just too much. Also, a boot script system would compromise our security and encryption.

2. I'll check it out. If it works in OpenAL, then it should be possible in SDL, because OpenAL is a mere wrapper library.

4. Then I'll guess there's no way around it. I'll take a better look at it then.

I mean after all I'm for 2 and 4 as well. I'm just a bit lazy to implement them. ._.;;;