ARC Legacy Edition - Engine Beta 2

Started by Blizzard, May 19, 2012, 02:57:22 pm

Previous topic - Next topic

Blizzard

May 19, 2012, 02:57:22 pm Last Edit: July 30, 2012, 01:24:23 pm by Blizzard
ARC Legacy Edition - Engine Beta 2





It's been a long time since the development of ARC started. And we have finally achieved a significant milestone: The beta version of the engine. Yes, it's true, the ARC Legacy Edition is almost complete. The editor will still take a while, but the engine is almost done.




Stuff that doesn't work

Now, there are obviously a few things that need to be ironed out and a few "missing features".


  • ARC wasn't fully tested with 8-bit and palette based PNG images. While in theory you should have absolutely no problems, this simply has not been tested. Why? Recently there have been changes in the code of loading images so I'm simply not sure if it will work seamlessly.

  • Bush depth will not work. Mainly because this will require additional sprites that could cause a slowdown, I'm trying to figure out a way how this can be done in a better way.

  • Alt+ENTER won't work. Currently April is being refactored massively for v2.x to be able to support new features and fullscreen switching on the fly is one of them.

  • If you press CTRL+Alt+Delete in Windows Vista/7 and try to return to the game, the textures will be all disposed. While you may be able to restore some textures by opening the menu or switching to another scene, you may not be able to continue playing the game properly until you restart it. Properly managed textures are also a feature of April v2.x.

  • RTP files cannot be accessed. All game resources have to be copied/moved into the game's directory.

  • MIDI is not supported. While currently our public statement is that MIDI will not be implemented at all, we have been made aware of a library that might provide the functionality we need after all. I'm not making any promises, but full MIDI support is something that may still be available once ARC Legacy Edition is released.

  • ARC creates a log file in "C:\ProgramData\ARC\GAME_TITLE" called "log.txt". Keep in mind that "C:\ProgramData" is a hidden directory and that you will be able to see it if you turn on visibility of hidden files on your system. Though, you can access it regardless whether it's visible or not by simply typing "C:\ProgramData" in the address bar of Windows Explorer.

  • If you plan on trying out some scripting, there are differences between RGSS and Zer0 RGSS. You can read more here. There are also additional undocumented classes such as the ARC module. For now I will only mention ARC::Version which will return the engine version and ARC.cfg_parameters which will return a hash with key-value pairs from the arc.cfg file so you can use them internally. There is also ARC.system_path which returns the path to the user directory where you should store save games and such (which is usually "C:\ProgramData\ARC\GAME_TITLE"). You can also access ARC.get_backend_id to get the special backend Window ID of the actual window in which ARC is running. On Windows this is the HWND.

  • Custom fonts may cause problems and unpredictable behavior, especially fonts with "weird" names. Be careful if you try to use custom fonts for now.






Download

You can try out a clean ARC project. This is also the official engine beta: Official ARC Legacy Edition engine beta 2
Keep in mind that this build does not include any resources. You should copy/move all RTP resources into the project's directory once you have unzipped it. Otherwise it won't run.




Testing the engine with your own game

You can try converting your own project into an ARC project. In this case, please follow the instructions from this topic. Remember that you will need to copy the .dll files, the Game.exe and arc.cfg from another ARC game. You can safely use the files from the official beta project.




How arc.cfg works

With every ARC game there is a file called arc.cfg which has a similar purpose like RMXP's Game.ini. In this file you have several configuration parameters. If one of the engine parameters is left out, the default will be used. You can also add your own keys and values and use them inside your scripts. These are the engine parameters:


  • Title: The name of your game that will appear everywhere.

  • Resolution: This is your game's resolution. It is defined as WIDTHxHEIGHT. If an invalid value is used, it will default to 640x480. Keep in mind when using custom resolutions that you will most likely need to edit your scripts because RMXP's default scripts were not designed to properly run in resolutions other than 640x480.

  • Fullscreen: Whether to run the game in fullscreen or not. Remember that switching with Alt+ENTER does not work at this time.

  • FrameRate: RMXP was hardcoded to 40 FPS. In ARC you can specify your own FPS value. Keep in mind that values different than 40 will cause a normal RMXP game to run faster or slower.

  • InactiveAudio: RMXP keeps the audio running if the window becomes inactive. ARC allows you to pause the audio while the window is inactive.

  • FontBaseSize: ARC uses internally a special font rendering engine. This defines the max font size for the game. A higher value will create higher quality font textures, but it also requires more GPU memory. The minimum size you should use is the maximum font size that you are using in your game. If you set it to a value lower than the maximum size, the generated texture will be populated with small fonts and during rendering they can appear blurred. The recommended value is twice as much as your maximum font size. e.g. If you are using somewhere a font of size 32, don't use values below 32 and the recommended value would be 64.

  • GameVersion: The game version is not something that is used by the engine, but you should probably specify a version here for convenience.



These keys/values can be accessed through ARC.cfg_parameters which will return a hash copy of the configuration parameters.




Try a working game in ARC

This download here is Chronicles of Sir Lag-A-Lot running fully on ARC: CoSLAL on ARC
You can simply download and play. The game has been tested extensively and was used as the main base for the code development. That means that not only RGSS was implemented, it was even tested with complicated scripts such as Tons of Add-ons and Blizz-ABS which introduce a heavy load of custom features that go far beyond the normal functionality of RGSS (such as custom input) and it was made sure that it works. This is also the development build v0.9.8.729.




The development team wishes you lots of fun with the beta. :)
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

tginick93

Hey guys.

So I was trying the latest build with CoSLAL and I have to say I'm very impressed with what you guys have done. (Far more impressed than what Enterbrain has done for the past years at least!)

I did encounter a few problems while running this. Hopefully this is the right place to post them.

Spoiler: ShowHide

I've played with CoSLAL with the RMXP engine before and I don't think that the transparency is like this.

Also I don't have screenshots of these, but on occasion, opening the chest in the first room or pressing F to open the menu causes a Visual C++ runtime error to appear saying that the application has requested the runtime to terminate it in an unusual way.

I would have given you guys more information about that second problem as I know from experience that debugging something with absolutely no information on where the error may be is like asking a blind person to pick a needle from the haystack. Problem is I'm not quite sure how to get a log or trace for this type of error. If any of you can tell me how to do it, I will gladly produce one for you the next time it occurs. :)

Anyway, congrats on reaching beta for the engine!

Blizzard

The "TFACTOR" (a fixed color value used in texturing) is not supported in some implementations of DirectX. I have encountered the exact same glitch when running CoSLAL on a Windows XP VM. Sadly, the color calculation to properly include color, tone and opacity can only be done through a pixel shader which has to use TFACTOR for opacity during texturing rendering. I don't think there is a way to fix that properly.

I'm not sure yet what could cause the runtime error, but I'm never able to get it to happen in a debug version. There might also be an issue with audio, but so far I was only able to get the bug to happen on another project when I exit the program.

The logs are located in "C:\ProgramData\ARC\Chronicles of Sir Lag-A-Lot" as described in this topic: http://forum.chaos-project.com/index.php/topic,11882.0.html
Obviously they are purged when you start the game so you should send us a log right after the crash happens.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

tginick93

May 20, 2012, 03:37:41 am #3 Last Edit: May 20, 2012, 03:44:06 am by tginick93
Hi Blizzard. I found the log:

Spoiler: ShowHide

[atres] initializing atres
[atresttf] initializing atresttf
[xal] initializing XAL
[xal] initializing DirectSound
[xal] audio system created: DirectSound
[xal] starting audio update thread
[zer0] initializing Zer0 Division Engine
[atres] registering font resource Arial
[xal] loading file Audio/SE/001-System01.ogg
[xal] loading file Audio/SE/003-System03.ogg
[atres] registering font resource Arial Bold
[xal] loading file Audio/SE/002-System02.ogg
[xal] loading file Audio/SE/028-Door05.ogg
[xal] loading file Audio/SE/030-Door07.ogg
[xal] loading file Audio/SE/056-Right02.ogg
[xal] loading file Audio/SE/044-Chest01.ogg


Unfortunately a quick look tells me that it isn't really useful to the problem at hand. So I took a quick look at Event Viewer and this is what I found. (I think it's slightly more useful! :D )
Spoiler: ShowHide

Faulting application name: Game.exe, version: 1.0.0.666, time stamp: 0x4fb751b9
Faulting module name: msvcr90-ruby192.dll, version: 1.9.2.180, time stamp: 0x4eec8da5
Exception code: 0xc0000005
Fault offset: 0x0002cb34
Faulting process id: 0xd44
Faulting application start time: 0x01cd364c3e27b5a4
Faulting application path: C:\Users\nick\Desktop\CoSLAL_on_ARC\Game.exe
Faulting module path: C:\Users\nick\Desktop\CoSLAL_on_ARC\msvcr90-ruby192.dll
Report Id: f9e59caf-a23f-11e1-8201-c8bcc8e14eb0


The only thing different between the logs (I have 2. Same fault offset.) are the process id and start time, which are probably irrelevant to the problem anyway. Hopefully this might help you guys with your debugging! (I really really hope it's not just me having this error -__-)

EDIT: So I checked and the exception code refers to a memory access violation. I'm going to check my RAM tonight and see if it's my computer that is causing the problem. If it is, well ram is cheap :P

Blizzard

Hm... Ruby crashed the game. Now the question is why. I hope it's not a bug because of the automatic optimization of the binaries. But at least that would explain why I am never getting this bug in a debug build. I'll look into it. I can usually reproduce the crash when I try using ARC for my own game as my own game uses even more custom stuff.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Memor-X

Quote from: tginick93 on May 20, 2012, 02:14:13 am
Spoiler: ShowHide



hay, thanks for the screenshot tginick93

assuming that the screenshot is from the latest build, the text hasn't changed from what i reported,

firstly, look at the numbers in the hud, they kinda look like they are melting,
in the pre-menu, look how a, o, s don't seem to look like how they are in "Nooblands" even if they are smaller,
there also seems to be some extra pixles onto of some letter in the pre-menu like with n, r
the thinkness on the o's aren't uniform, they seem to be thinner at the top than the bottom

it just something that's getting in my face, i might just be nit picky but it does kinda seem a bit off to me

Blizzard

That's because of the font renderer. You can actually use a different FontBaseSize and reduce that effect since the font is rendered in that size and then resized dynamically.
I can actually include a parameter to use a separate font texture for every font size. This would solve the problem completely, but it would cause a heavy increase in memory usage if many different sizes are used.

Though, I'm not entirely sure if I set the rendertarget to use Linear Interpolation or Nearest Neighbor. o.o; If I set it to linear, it's no wonder the font turns out so pixelated since it really shouldn't. I'll put it on my TODO list.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

tginick93

Who would have known. Memtest86+ returned thousands of errors on the first test -____-''. And this computer is relatively new too.

Long story short, the memory access violations are probably due to some faulty RAM on my side. I'm gonna go out and shop for new memory tomorrow and try to reproduce the error again, but new RAM should fix the problem. Sorry about for the false alarm blizz. :shy:

DarknessSurrounds

I wasn't sure where I should post this, here or in the topic for the RMXP project converter.

I've been playing around with the project converter and the beta engine the past couple days, trying to convert projects, and I wanted to post my experiences and report a few bugs I've found.

A few of the projects I've converted simply hung at a black screen or immediately crashed.  Reviewing the log files, it seems that the projects I tried were mostly trying to load data from MapInfos.rxdata, which obviously doesn't exist.  Any script that reads the name of a map would do this.  Commenting that line out usually allowed the project to run.

The first problem I found was, when using switch statements, at some places in my code I had something like:


case a
when 1..5:
  puts "It's between 1 and 5"
when 6:
  puts "It's 6"
when String:
  puts "You passed a string"
else
  puts "You gave me #{a} -- I have no idea what to do with that."
end


Notice the colons after the case statements.  ARC doesn't like these and crashes when it encounters them.  RMXP however would run them just fine.  This is pretty unimportant, but I figure it's worth mentioning.

A massive problem I ran into was trying to convert an old beta build of my project.  This is mostly an ungodly hacked together mess, and I'm eventually going to refactor the whole thing and build it off the base ATOA 3 battle system, but I wanted to try and convert it anyway.

It kept crashing with weird errors, but I eventually figured it out.  The problem was that I had used an old version of ForeverZer0's Gemini script editor to edit the Scripts.rxdata.  It was a long time ago, and I remember there being a bug where it would improperly inflate/deflate certain characters, namely Japanese characters.  It would replace them with a bunch of garbage data, and when reloaded and saved again, it would replace that garbage data with even more garbage.  Reviewing the individual script files, I found that many of them were HUGE, like 5-6 MB's each.  Most of these were just filled with that garbage data, it was mostly characters like: ƒ¼Ã

Anyways some of these 6 MB files, after I manually removed all the garbage data, were only 40-50 KB, so there was an obscene amount of junk that Gemini had inserted in there.  Not hating of Gemini or ForeverZer0, it's an awesome app, but anyone who had used Gemini on their project should beware of this bug.

Anyway, after many hours, I finally got the project to run!  However it would crash with a Runtime Error when I tried to pause/bring up the menu.  This may have been due to the use of several external scripts and libraries I was using, but I really don't know.  I'm not too concerned with getting this particular project working, I'm more concerned about the next bug I found.

The refactoring of my project is based on ATOA 3.2 (http://save-point.org/thread-2136.html).  RMXP runs this with no problems.  However, when I convert it to ARC, it, as well as a clean ATOA 3.2, it immediately crashes with the error:

code converter not found (ASCII-8BIT to UTF-8)


I thought that one of the files might be in the wrong format, so I used an app to manually convert all the script files to UTF-8.  However I still get the same error.  Any idea why this would be happening?




In any event, great work guys!  Congratulations on releasing the beta version of the engine, keep up the great work!  I'm sure once the editor is done and a default set of ARC scripts have been written for us to build off, we will run into less problems.  But this is progress!

ForeverZer0

Using colons is depreciated in Ruby, and I *think* it may have even been removed in Ruby 1.9, in which case that is a rare error from upgrading to a higher version of Ruby, and is going to need fixed in the script.

Yeah, the first version of Gemini had serious string encoding issues. :)  All fixed now, though ;)

The converter should be outputting the files in UTF-8 format by default, and conversion should not be necessary. If it doesn't, then that needs fixed. You can also force encoding in Ruby by either setting the KCODE, or via each script by adding the following header to the very top line of the script:
# encoding: UTF-8


I am done scripting for RMXP. I will likely not offer support for even my own scripts anymore, but feel free to ask on the forum, there are plenty of other talented scripters that can help you.

Blizzard

May 20, 2012, 05:04:09 pm #10 Last Edit: May 20, 2012, 05:09:55 pm by Blizzard
1. Ryex hasn't updated the converter to change this:

load_data("Data/MapInfos.rxdata")


to this:

ARC::Data.load("Data/MapInfos.arc")


which is obviously used by a couple of custom scripts (e.g. Map Location). You can actually do that manually before using the project converter and it should run fine afterwards.

2. The colons are not valid Ruby syntax, at least not valid Ruby 1.9.x syntax. Just like F0 already said. This was probably there because one of the languages that were used as inspiration for Ruby was Python which had to have a colon at the end of lines that start a new block (such class definitions, method definitions, loops, conditional branching, etc.). Ironically Python does not have switch-case/case-when blocks (at least not in the 2.x versions that I used).

3. About Gemini and UTF8: What F0 said.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

DarknessSurrounds

Ok thanks for the replies guys!  I did get it working!  I think the error might have been caused by the fact that I had non UTF-8 characters in my script names (the filenames).  specifically these:

« »


Anyways removing those characters from all the filenames and adding the encoding comment at the top of all the scripts did the trick.  You may want to have non UTF-8 characters stripped from the script names when they're converted.

Also one other thing of note that has caused a couple problems: the array method nitems was removed in Ruby 1.9.  Some of my scripts used that and so it was causing problems.  It can be fixed by redefining the method for class Array:

class Array
def nitems
count{|x| !x.nil?}
end
end


I'll make a post if I find any other issues.

Ryex

May 20, 2012, 08:04:04 pm #12 Last Edit: May 20, 2012, 08:23:06 pm by Ryex
I'll go update the converter real quick, I did my best to remove invalid characters from file names but I wasn't thinking about UTF-8 characters.

EDIT: the DL link in the converter topic is updated it should replace the mapinfos lines now as well as force US-ASCII encoding on script names before scrubbing them for invalid characters
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

tginick93

First I would like to apologize for the double post. :)

Anyway, after Apple told me that my memory was fine, I tried again to find the cause of the crashing, and I think I came up with a probable culprit: the Ü character from Über potion.

I noticed that most of the message windows worked fine. For example, talking to Arshes again did not result in the crash. The crash did not happen if I skipped the chest and went directly into the next room. Thus, it seems that the crash only happens when opening the chest.

I tested this by downloading the original CoSLAL and modifying the chest event to show the acquisition of the Über potion twice, except in the first time, I used a "U" instead of a "Ü." (Of course I converted to ARC format first) The first message displayed fine, but as soon as I hit space, BAM crash.
In the event that it did not crash, the message appeared more like "Áber potion". Then, upon exiting the game, I get the standard application crash (i.e. Game.exe has stopped working blah blah blah). I would get a log, but since the VC++ runtime error happens far more often than the exit crash, it's hard to get a log :shy:. All I remember is that the last entry is
[atresttf] destructing atresttf (or something along those lines)

Anyway, I'm not sure why this would occur since I read that your hltypes should be able to work with these kinds of characters, but it seems that some heap corruption (correct term?) is occurring on my end.
Also, I'm not sure if anyone else is having the issue. (Someone else with a MacBook check :). If not, then my computer be fked up xD)

Hope this helps guys! Really hope I'm not too much of a bother :)

Blizzard

May 21, 2012, 02:48:52 am #14 Last Edit: May 21, 2012, 02:54:21 am by Blizzard
@Ryex: I think I have committed a Ruby script to extract all scripts and convert them to files. IDK if I paid attention to UTF8 chars, but I definitely replaced the characters that were invalid as filenames (at least as far as I remember). Look up the RMXP directory, there should be somewhere an extract_scripts.rb file.

@Eclipse: As far as I see, you can basically do "array.compact.size" to get the same thing.

@tginick93: The "Über Potion" thing is something that I think RMXP/Ruby already messed up. I think the string wasn't properly encoded into UTF8 from the begin with. Though I have experienced a crash at the exact same moment where you hide the message from the chest.

I am splitting this topic off now, because these things should all be in the beta topic and not here.

EDIT: Done.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

Ryex

Lol, Blizz, I was actually more through than you in my character striping :P
I no longer keep up with posts in the forum very well. If you have a question or comment, about my work, or in general I welcome PM's. if you make a post in one of my threads and I don't reply with in a day or two feel free to PM me and point it out to me.<br /><br />DropBox, the best free file syncing service there is.<br />

Blizzard

Good. I basically just did the basic thing of removing unsupported filename characters. :>
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

G_G

I dunno where I would post this exactly so I'll post it here. It's more of a question on scripting practice. Since the engine allows for different resolutions, would it be best to try and implement that into your script? Have windows try and auto resize/fit to the resolution? Or even leave it as an option so end-users don't have to deal with repositioning everything? Or is that just bad practice? I was experimenting with how I would go about doing it and the result didn't turn out too bad.

Basically what I did was take the difference of Graphics.width and 640 and distribute the amount evenly to the two windows that are side-by-side.
    w = ((Graphics.width - 640) / 2)
    @cats_window = Window_Base.new(0, 0, Graphics.width, 64)
    @command_window = Window_Command.new(160 + w, ["Quest 1", "Quest 2", "Quest 3"])
    @command_window.y = 64
    @quest_window = Window_Base.new(160 + w, 64, 480 + w, Graphics.height)


576x416
Spoiler: ShowHide


640x480
Spoiler: ShowHide


800x600
Spoiler: ShowHide

Blizzard

Honestly, supporting multiple resolutions is the better practice. But the thing is that you have to be careful when designing your GUI and it turns out to be more work for you. So it's entirely up to you whether you want to support it or not. ARC's final version's scripts will support resolution changes properly. So as for the Legacy Edition with RGSS, it's really up to you.

BTW, my suggestion for your examples would be to have fixed height for the top window (as you already did), a fixed width for the left one and only resize the right one.
Check out Daygames and our games:

King of Booze 2      King of Booze: Never Ever
Drinking Game for Android      Never have I ever for Android
Drinking Game for iOS      Never have I ever for iOS


Quote from: winkioI do not speak to bricks, either as individuals or in wall form.

Quote from: Barney StinsonWhen I get sad, I stop being sad and be awesome instead. True story.

G_G

Alright, thanks. I'll keep that in mind as I start to develop some scripts and whatnot.