Chaos Project

---

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 (http://forum.chaos-project.com/index.php/topic,10474.0.html). 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 (http://downloads.chaos-project.com/arc/ARC%20Legacy%20Edition%20Engine%20Beta%202.zip)
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 (http://forum.chaos-project.com/index.php/topic,11843.0.html). 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 (http://downloads.chaos-project.com/arc/CoSLAL_on_ARC.zip)
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.

---

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.


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!

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.

Hi Blizzard. I found the log:



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 )


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

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.

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

Spoiler: ShowHide

(http://dl.dropbox.com/u/3431456/transparency.png)

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

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.

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:

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:



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:



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!

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:

1. Ryex hasn't updated the converter to change this:



to this:



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.

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:



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

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

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 :)

@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.

Lol, Blizz, I was actually more through than you in my character striping :P

Good. I basically just did the basic thing of removing unsupported filename characters. :>

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.


576x416


640x480


800x600

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.

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

I forgot to mention for scripts:

If you want to check whether your script is being used in ARC or in RMXP, simply check for ARC.

in regards to supporting multiple resolutions scripting practice, wouldn't it be far more work that what it's worth, a change to the resolution mid game would require you to not only make sure that Windows are re-sized/re-positioned but also since we use sprites a change of resolution would just allow the player to see more of the map which means you will have to keep that in mind when making events disappear when they go off screen (unless someone suggested a If position is off screen condition) and even without that, if you made an event walk off screen and you have the player wait, larger resolutions would require either the event to move faster or the player to wait more and even if you try and hide that with a Map Zoom, it will be noticed very easily

wouldn't a better practice is to choose a resolution and stick with it since unless someone creates a plugin for ARC that allows it to import Vector based graphics mid game resolution change won't make any different graphically unlike what it does in AAA games (and maybe some Indie but i can't think of any off the top of my head.....wait, does Bastion count....and did it even have resolution change) and the reason why you change the graphics via resolution is to greatly reduce the amount of data that is being possessed and rendered

Quote from: Memor-X on May 24, 2012, 06:40:04 am
mid game resolution change

I don't think you'll be able to change the resolution mid-game. What I was referring to with scripts auto-sizing for resolution is whatever resolution the developer decides to choose, he won't have to worry about tinkering with the script to make it fit properly.

Technically you will have those API calls available, but they won't be used by the default scripts.

@Memor-X:

Who said anything about being able to change the resolution mid-game? Yes, ARC will provide script calls for doing that, but they won't be included in the default scripts. If somebody wants to do that kind of thing, they are on their own. We are talking about a script working in multiple resolutions, not about changing the resolution during the game.

AAA games don't use vector graphics and neither do Indie games. They are basically all 3D and rendering a 3D scene in a different resolution is completely different in concept than rendering a 2D scene. In 2D games the only realistic solution for using different resolutions it that the graphics are either scaled to fit into the resolution or the game's contents include graphics in different resolutions (e.g. one graphic for a 1024x768 title screen, one for a 1600x1200, etc. or one big graphics that is simply being cropped on smaller resolutions).

It just crashes when i run it.
I click to run.. it acts like it's about to start.. but then quickly crashes.

I will be a real ass here and quote myself in a condescending tone.

Quote from: Blizzard on May 19, 2012, 02:57:22 pm
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.

Sorry.... :(  i missed that part...

Hey, are you guys going to release how you implement the Window class?  I want to eventually extend it to function like a better RMVX window class (basically multiple stretched/tiled background layers at different opacities).  I think I remember you saying something about supporting about the ability to do this eventually.  Am I just getting way ahead of myself here?

we implemented the window class in C++ so it's not a simple as extending it with ruby. but for the full version of ARC we are planing on having a much improved window class, Blizz has a cool I deal that I can't remember at the moment. he hasn't posted it anywhere that I know of so I'll let him fill you in

I once made a WindowX class in RMXP for somebody that would allow you to customize the window class a lot more. You were able to define how big the borders were, possible background except the window skin, a scroll bar if the window's contents don't fit in the window, etc. It was part of a complex menu system that needed some really custom stuff. I realized that the best way to make it work is simply to rewrite the window class. Any other solution would have been just half-assed and I would have ended up with more problems in the end.

All of these features and more will be available in ARC's window class. The awesome thing here is that AprilUI already supports a ScrollArea and ScrollBar object so it's just a matter of skinnging and making a Window class which is basically a composite Object that uses them.

That sounds awesome!  I take it this functionality is going to wait until the full version?

Yes and no. The AprilUI based Window class will be available in the full version later. But I will already implement some additional stuff in the RGSS Window class. But this will wait until ARC-LE v1.1.

I just have one question for the engine. Earlier I found that certain things were not rendering properly on my computer.

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

Spoiler: ShowHide

(http://dl.dropbox.com/u/3431456/transparency.png)

Does this mean that the engine will require a relatively new system (or gpu for desktops) to run properly on? I'm just curious about this because my computer is a mid-2010 model. It's relatively old yeah, but I can still run graphically intensive games like Assassin's creed with no problems other than lag on it.

If it has a Pixel Shader, it can run ARC normally. And Pixel Shaders have been around for 10 years. If this is happening to you, your drivers aren't working right.

Fcking apple... Well thanks for the clarification :)
Can't wait for the first release!

If it's any consolation, I am actually trying to come up with a solution for this. xD The problem happens because during the texture rendering stage you can specify an additional constant color that you can then use in the shader calculation. The problem is that not all drivers support it. I am having exactly the same problem in a virtual machine. Since having no opacity is not really an option, I will have to come up with a solution for this problem.

EDIT: Alright, I just checked. It's simply not possible. The card has to support pixel shaders. You will notice that nothing works, neither opacity nor color nor tone.

It's weird, nVidia says my card supports shader model 4 (this is a gt 330m) so there's probably something wrong with either the card or the driver. Color works fine, it's only the cloud layer that's rendering improperly which means pixel shaders are supported on my card (according to what you said). I'll have my friend check if this problem exists on inferior hardware.

Thanks for letting me know. Still looking forward to the final release :)

That may be true, but if you are running a virtual machine, you are actually using just a generic driver provided by the virtual machine which is offered only a generic interface to the graphic card from the host OS. So it's not a problem with hardware, it's because the virtual machine doesn't know you have a GT 330M. And I'm not sure if that can be fixed somehow.

I don't use a vm. This problem occurs when I run ARC on my physical machine (W7 dualboot config)

Sorry for double post, but my friend tried the engine and told me what happened.

On an integrated nVidia geforce 9300m (this is not an apple computer): same thing happens.
On an integrated Intel 4000 HD (on a recent Macbook air): crazy shit... along with the transparency problems.
Also my card (the GT 330m) is discrete, not integrated.



EDIT: I would like to point out that the transparency issues do NOT occur in v 0.9.4.620

Yes, that is really weird. But there seems to be some sort of consistency. Either the tile IDs aren't read properly (which doesn't make sense because then everything had to be messed up and there couldn't be a piece of the windowskin on the map) or there is some problem with texture creation. It's as if the buffer of another texture is on the tile's buffer for some reason.

These graphics cards so finicky... >.>

But as I said in an earlier post, the cloud layer does render properly in any version before 0.9.6. Did a large change in graphics processing take place in the transition from 0.9.4 -> 0.9.6. The thread doesn't really give much information on that.

I think that's when I added pixel shaders. I'd love to go back, but the one before can't render it how RMXP does it. That's why I switched to pixel shaders in the first place.

Hmm i did notice that too in 0.9.4. However, I'm still worried about the compatibility ARC has with different GPUs. Obviously the nvidia 9300 is pretty much obsolete so rendering problems shouldnt be unexpected. But the Intel 4000 HD is a relatively new GPU (even though it's integrated) and is present in a lot of notebooks (macbooks).

Is there really no one else with this problem on a physical computer?  :???:

As I said, the problem is not the computer but the driver. I could try to make all of this work using single-texture multi-pass, but this is yet again something that some cards don't support.

Oh! Im so sorry I misunderstood you back there. I kept thinking that the problem was because my physical card (and not the driver) doesn't support whatever shader features you guys are using.  :^_^':

Guess I'll talk to apple about it when i have the chance. Thanks for clarifying.

The problem is that your running windows on a MAC.  I imagine that driver support for windows for Apple hardware is anything but excellent.  when we build the MAC version of the engine you can just run it under the MAC OS and have no problems :).

Support for apple hardware on windows is VERY excellent. :) The mouse works like a piece of junk, just discovered the gpu drivers are crap and my brightness settings reset with every boot.

Anyway that's very good to hear ryex. But i imagine other mac users running windows will encounter the same problem?

It's almost as if apple DOESN'T want us running windows on our macs... ;)

your post contradicts itself and then speaks truth... I approve.

but yes, other mac users on windows will likely have the same problem.

when they made parallels so you could run windows on a mac they basically used DuctTape(TM) "An adequate fix for everything". It works, quite well for most things really, but it falls short when you do a bit of exploring and sew a few boundary cases

I dislike apple not for it's products (they are for the most part quite impressive), but for it's development and user experience philosophy, which is "We own you, We control it, it's for your own good"

On that note, I should probably post my experiences with the last few dev builds.

0.9.8.652: Everything seems to be working properly



0.9.8.666: Major problems.  Namely the transparent parts around the enemies, and what looks like some random texture issues.  Also I'm getting the misplaced tiles problem.  What's strange is that it seems to change every time I go between one map and the next.  This might be a problem with the tile buffers.



Beta Build: Same as above

I should note that I did not experience any problems with the pixel shaders used in the fog layers.  This laptop is a Lenovo x220 Tablet hybrid with an Intel HD Graphics 3000 (GT2+) GPU.

I'll repeat these tests in a few days on my Desktop, which has an XFX Radeon 6870 1GB (256 bit) graphics card.

Thank you. It will be very useful to know that the problem did not appear in r652.

Alright, I just repeated the tests on my desktop.  It has a XFX Radeon 6870 1GB (256 bit) Graphics card, purchased last year.

There are no problems.  Everything works as it should, the 3 builds are indistinguishable.  I guess this card supports pixel shaders no problem.  It's kind of weird, because my laptop is actually newer than my PC graphics card, but apparently doesn't support pixel shaders.

again, it not your computer, it's the driver for your card. as your on Mac run windows your hardware integration and thus your driver is not of the greatest quality. your computer and graphics card are great, it's the fact that your running windows on that Mac.

Actually...

Quote from: Eclipse on July 21, 2012, 04:01:36 am

I should note that I did not experience any problems with the pixel shaders used in the fog layers.  This laptop is a Lenovo x220 Tablet hybrid with an Intel HD Graphics 3000 (GT2+) GPU.

...^^;;

@Eclipse, try updating drivers?

I just updated to the latest graphics driver, which was released on 6/21.  Same problems  :uhm:

Quote from: tginick93 on July 26, 2012, 02:49:10 am
Actually...

Quote from: Eclipse on July 21, 2012, 04:01:36 am

I should note that I did not experience any problems with the pixel shaders used in the fog layers.  This laptop is a Lenovo x220 Tablet hybrid with an Intel HD Graphics 3000 (GT2+) GPU.

...^^;;

@Eclipse, try updating drivers?

oh, my mistake.  interesting that such a new card is buggy like that.

I have uploaded the second beta of the engine and update the CoSLAL example as well to use beta 2. There wasn't changed much, but the underlying libraries have been refactored and improved ever since. Beta 2 should work properly with the newest RMXP2ARC project converter.

Also, now you can 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.

EDIT: Ah, shit, wait. I messed up with the data conversion. ._.

EDIT: Ok, Beta 2 was fixed and reuploaded. The CoSLAL upload will take a few more minutes.

Fixed some bugs that made my game crash and now I get this o.0 :
(http://i50.tinypic.com/krxjn.png)

Note: The login/server selection works fine, this happens after I login.

I am not exactly sure why this happens. :(

Sometimes I would get a flash of the screen after logging in but then it crashes again :(
The log file is not much of a help either:


(http://www.myfacewhen.net/uploads/321-sad-pikachu.jpg)

(http://i.imgur.com/KeS1n.png)
Any idea how to fix this, Blizzard?

Quote from: Blizzard on July 30, 2012, 01:26:43 pm
I have uploaded the second beta of the engine and update the CoSLAL example as well to use beta 2. There wasn't changed much, but the underlying libraries have been refactored and improved ever since. Beta 2 should work properly with the newest RMXP2ARC project converter.

I'm already using beta 2.

Quote from: Blizzard on July 30, 2012, 01:26:43 pm
the newest RMXP2ARC project converter.

If I remember right, the old ones had problems with conversion of UTF8 characters.

Also used the latest version of the project converter.

Then something with your script is broken or Ryex hasn't updated the converter. Beta 2 was made especially to address this issue.

I'm sorry but the code converter error keeps occuring, and I'm using the newest project converter and the newest version of the engine.

You will have to wait until Ryex can take a look at it.

Hi people! Just tried the beta 2 with my game. I think that if my game works, everything else will do ahahahahaha! But anyway...

I'm using binaries from the CoSLAL just in case, and the RMXP2ARC converter linked at the converter's tutorial post. They seem to be working fine.

So, here is some of my experiences. First "problem" I encountered is that the game's window caption can't use characters like ö, it crashes the player.

After that, it starts fine, renders my splash screen (which is just a fullscreen sprite appearing and dissapearing). Then, it goes black and just closes, no error message or anything. One of the possible causes can be that I use the FMOD Ex script, for loop support and save/load playing position. Anything else, pretty vanilla, as after the splash comes the title screen, which consists of sprites and a battle animation.
Another thing I'm using is Glitchfinder's input scripts (full keyb and gamepad), but it's not a problem, I have Tab key as "speed-up" key, and it works fine.

Anyway, I will continue testing, maybe Mode7 or something, or XAS, or any of those very used scripts, and I'll test my RomaSaGa BS,
Orochii Zouveleki

if your games uses external libraries like FMOD or Mode 7 your going to run into problems ARC's binary isn't going to be compatible with most of dll's thouse scripts pull in as they were specially compiled for RMXP's binary

the 'ö' in the window caption is probably fixable as it's a "simple" matter of enabling Unicode support for the window caption. I put "simple" in quotes because in actuality this is handled by APRIL and that's something Blizz deals with atm (not that i can't, I'm simply not familiar with that particular part of APRIL).

Actually I was having no problems with this on ARC CoSLAL without any modifications, but I'll take a look at it anyway.