Lyon

Discuss how totally awesome Bang! is here.

Moderator: Terryn

User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: Lyon

Post by Saxxon »

For those still interested in this project, the source is now being hosted as a Google Code project here:
http://code.google.com/p/roton-zzt/

Because multiple languages are used, you might not have the ability to open the entire solution in an Express version of the software. Since I am moving away from Visual Basic into C#, the Lyon frontend will eventually be ported over so that the whole solution can once again be fully opened in an Express version.

If you would like to contribute anything to this project, please let me know and I can add you to the list of contributors, and grant commit access.

User avatar
Commodore
fgsdfs
Posts: 2460
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Re: Lyon

Post by Commodore »

Check out this: http://www.mono-project.com/Main_Page its for running .Net applications on linux and macs. I'd like to try and compile it for my linux box, but wouldn't I need the IDE?
*POW* *CLANK* *PING*

User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: Lyon

Post by Saxxon »

No. The C# compiler is a commandline tool. The IDE exists only to make writing the code easy.

User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: Lyon

Post by Saxxon »

I found out that the ability to open up solutions that use multiple .NET languages doesn't exist in the Express versions. That's going to limit the ability of people to contribute very heavily. Therefore, I will be porting all VB code to C#. Also, I will be changing the target framework to 4.0 so that SlimDX can be used, which should provide much better audio and video capabilities. As a side effect, Win98 and 2000 will no longer be supported, and XP will need Service Pack 3.

After making the entire project C#, contributors should be able to use the free Express edition of Visual Studio with the solution.

These changes probably aren't going to affect many people (I'm thinking most of you already at least have XP SP3). They're all necessary to make sure that the program is both efficient and easy to contribute to.

User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: Lyon

Post by Saxxon »

I took a look at the "offscreen player" on the title screen. It turns out the memory directly after the board data is the object data. The player is the first object, naturally. Some of the player's data is not used. Therefore, we can use the unused part of the player data on each board to plant an offscreen element of our choosing! This means offscreen objects are possible on any board with a little hex editing:

- The player's unused data on each board would need to be modified to keep the offscreen object present.

- The code still needs to exist on every board and one object will still be consumed from the total count. When switching boards, ZZT clears its code cache.

- There's enough room in the unused data to have BOTH an offscreen player and offscreen object!

Roton is not compatible with this because memory access this way is illegal. (I'm going to implement a bit different of a system later on.) Perhaps I'll also throw together a demonstration world.

User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: Lyon

Post by Saxxon »

For the sake of supporting all the fun memory corruption and out of bounds access stuff that may actually be useful (like the hole-less title screen for example) I am getting closer to fully implementing the memory layout used by the program.

In this screenshot I demonstrate how the heap is emulated. Both code and offscreen board data is stored in a similar manner by ZZT. While there won't be a way to cross heap boundaries, ZZT has good enough management of this that it isn't needed. However, boundaries can be crossed in a variety of ways by out of bounds array access (which makes the hole-less title screen work.)

I considered using a hash table, but C# managed code doesn't deal much with pointers at all, so there's no advantage (I would probably use the pointer as the primary key.) Each entry is uniquely identified with a number.

None of this matters to non-coders. So what does this mean for you? It makes possible some of the useful things you aren't supposed to do with ZZT that you can do with out of bounds array access. This really is one step closer to just emulating the DOS system itself. By emulating things this closely, we get (desired) accurate corruption for free.

I plan to make it so you can open the memory up in a hex editor of sorts to observe and tinker with other values. Just note that if you do some really wacky stuff, some editors might crash.

Overall, this is turning out to be a fantastic development.

Edit: Lol, "house of bluescreen".
Attachments
heapemulation.png

User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: Lyon

Post by Saxxon »

I got most of the code moved over to the new system. You'll see Lyon running with its hex dump in a file to the right. That hex dump shows that the memory layout is identical to the shared memory layout ZZT uses (if you have ever looked at the game in IDA, you will see some familiar structures and offsets).

Surprisingly, the performance hit doing it this way is actually very small. There's also the added benefit of not having to emulate the heap in the same fashion. (Because of the way memory management works with object code and offscreen board data, you wouldn't be able to get practical results by crossing those boundaries anyway).
Attachments
memblock.png

User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1429
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Re: Lyon

Post by Quantum P. »

Wow. This project has really come a long way.

This sort of development is really neat to me, because I love realism and attention to detail. I guess I'm a purist of some sort. :-)
Saxxon wrote:This really is one step closer to just emulating the DOS system itself.
For a while now, I've wondered about writing a ZZT world that executes arbitrary x86 code. I wouldn't recommend it as anything more than a curiosity, but you could automatically load fonts/palettes, trick people into running a ZZT lookalike of some sort, write a virus more technically sophisticated than Redmage's... (please don't do that last thing)

User avatar
Smilymzx
I hope she made lotsa spaghetti!
Posts: 180
Joined: Sat May 20, 2006 2:58 am
Location: LocacoLocacoL :LoL!

Re: Lyon

Post by Smilymzx »

XVI32 is the best hex editor, I use it too!

Also... Great job on this. You are the best!!!

Spectere
wants to have your babies.
Posts: 83
Joined: Wed Jan 26, 2005 11:13 am

Re: Lyon

Post by Spectere »

This is .NET! I know this!

Image

Image

Very nice job on the original code, Saxxon! This was unbelievably easy to get working with Mono thanks to everything being modular. The amount of work that you've done to get Roton to behave like ZZT down the tiniest detail is incredible.

The first thing that I did was rewrite the GUI in C#, since I haven't coded in VB.NET in nearly a decade, and since that's the only piece that was still written in VB. I was able to get a build without audio support up and running quickly on Linux and OS X, and the same build worked flawlessly on Windows as well. It's still using Windows.Forms, and considering Lyon doesn't use any features that aren't supported under Mono I figured that a GTK# port wouldn't be particularly productive.

I ended up throwing together some sound support using SDL_Mixer (via Tao.Sdl), but it sounds quite bad at the moment and I haven't had a chance to narrow down the cause yet (mostly because I should have been in bed hours ago). I haven't tried Lyon on Windows yet, so I'm going to play with that a bit tomorrow before I obsess over this too much. :) As soon as I narrow down the audio issues I'll upload my code changes (probably some time tomorrow evening).

User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: Lyon

Post by Saxxon »

Quantum P. wrote:Wow. This project has really come a long way.

This sort of development is really neat to me, because I love realism and attention to detail. I guess I'm a purist of some sort. :-)
Saxxon wrote:This really is one step closer to just emulating the DOS system itself.
For a while now, I've wondered about writing a ZZT world that executes arbitrary x86 code. I wouldn't recommend it as anything more than a curiosity, but you could automatically load fonts/palettes, trick people into running a ZZT lookalike of some sort, write a virus more technically sophisticated than Redmage's... (please don't do that last thing)
The problem with writing x86 code to be executed in ZZT is that the location of this code is going to differ depending on any other TSRs being run, etc. DosBox runs with a memory configuration that you're unlikely to find on any other real DOS machine (because it emulates certain things without occupying conventional memory for a driver). We can be certain where RELATIVE positions are, because the data structures do not change relative positions or order. Also, the board unpacking code checks for the end of the board data by comparing if the current Y position is 26 or greater. It breaks the loop if so. So once you hit that point, you can't really change the pattern it outputs. Even if you put a 256 count at the very last tile, you'll only be able to write consistent values partially through the object data.
Spectere wrote:Very nice job on the original code, Saxxon! This was unbelievably easy to get working with Mono thanks to everything being modular. The amount of work that you've done to get Roton to behave like ZZT down the tiniest detail is incredible.

The first thing that I did was rewrite the GUI in C#, since I haven't coded in VB.NET in nearly a decade, and since that's the only piece that was still written in VB. I was able to get a build without audio support up and running quickly on Linux and OS X, and the same build worked flawlessly on Windows as well. It's still using Windows.Forms, and considering Lyon doesn't use any features that aren't supported under Mono I figured that a GTK# port wouldn't be particularly productive.

I ended up throwing together some sound support using SDL_Mixer (via Tao.Sdl), but it sounds quite bad at the moment and I haven't had a chance to narrow down the cause yet (mostly because I should have been in bed hours ago). I haven't tried Lyon on Windows yet, so I'm going to play with that a bit tomorrow before I obsess over this too much. :) As soon as I narrow down the audio issues I'll upload my code changes (probably some time tomorrow evening).
This is fantastic! I'm really happy to see you were able to get it working. One thing to note is that the branch I am working on is actually not on the GoogleCode webpage, and the codebase has changed quite a bit since. The good news is that all the code is still very modular, so all that should really be needed is tweaking your frontend to work with the new library. Once I feel that the new memory-layout-conscious build is ready, I'll let you know and you can adjust your frontend to work with it. All you should really have to do is change a couple functions you call in Roton, and which classes you instantiate. It shouldn't take too much longer as almost all the original code has been modified to fit with the new memory layout framework.

You'll also be relieved to know that the entire codebase is now C#. :)

Spectere
wants to have your babies.
Posts: 83
Joined: Wed Jan 26, 2005 11:13 am

Re: Lyon

Post by Spectere »

Saxxon wrote:This is fantastic! I'm really happy to see you were able to get it working. One thing to note is that the branch I am working on is actually not on the GoogleCode webpage, and the codebase has changed quite a bit since. The good news is that all the code is still very modular, so all that should really be needed is tweaking your frontend to work with the new library. Once I feel that the new memory-layout-conscious build is ready, I'll let you know and you can adjust your frontend to work with it.
The frontend was basically a straight port of what you had, except that it initialized a "RotonSDL" class for audio instead of the MDX class. I actually could have just modified the VB.NET form to accomplish the same thing, since Mono does support VB.NET, but I wanted to make sure that I could still grok VB. :) There's really nothing in the codebase outside of RotonDX9 that Mono can't handle.

Moving forward, I think the best path to take would be to either have Lyon select an audio class based on the OS used and/or user choice (i.e. defaults to RotonDX9 on Windows and RotonSDL on other platforms, possibly with a means of changing the default), or to just completely switch to a cross-platform library like SDL. The former should be trivial to implement by implementing a basic plugin architecture, and the latter should be even, um...trivialer.

If the DirectAudio output is maintained, it would probably be best to switch to another wrapper like SlimDX. Managed DirectX hasn't been updated and is no longer under maintenance. In fact, I think I'm going to take a crack at it now.
Saxxon wrote:All you should really have to do is change a couple functions you call in Roton, and which classes you instantiate. It shouldn't take too much longer as almost all the original code has been modified to fit with the new memory layout framework.
I assume that the Audio/Video/Input/etc interfaces that Roton exposes are basically the same as the GoogleCode repo?
Saxxon wrote:You'll also be relieved to know that the entire codebase is now C#. :)
Image

User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: Lyon

Post by Saxxon »

Spectere wrote:Moving forward, I think the best path to take would be to either have Lyon select an audio class based on the OS used and/or user choice (i.e. defaults to RotonDX9 on Windows and RotonSDL on other platforms, possibly with a means of changing the default), or to just completely switch to a cross-platform library like SDL. The former should be trivial to implement by implementing a basic plugin architecture, and the latter should be even, um...trivialer.
I'm already familiar with SlimDX (in fact, that's what the memory layout build is using). I could probably just port that code over to the trunk and throw away MDX references easily. As for SDL, I can't say I'm familiar enough to know how to do that yet, but once I get SlimDX squared away I'll be sure to make the interfaces generic enough to write a wrapper easily.

I just pushed an element bugfix (Monitor defaults were messed up) and the C# version of the frontend which is literally a direct port of the VB code to the GoogleCode repository. #BECOME MONITOR should work now.

The memory layout project is actually in a separate repository, but that one exists solely for backup and version control. I'll be merging that one back into the trunk on GoogleCode sometime soon now that I have a proof-of-concept build.

Spectere, if you would like to contribute, I can give you commit access to the repository. I would be thrilled to work with others on this project, and if you can assist me in putting together something more multiplatform-friendly, I think it'll benefit the community greatly.

Spectere
wants to have your babies.
Posts: 83
Joined: Wed Jan 26, 2005 11:13 am

Re: Lyon

Post by Spectere »

Saxxon wrote:I'm already familiar with SlimDX (in fact, that's what the memory layout build is using). I could probably just port that code over to the trunk and throw away MDX references easily. As for SDL, I can't say I'm familiar enough to know how to do that yet, but once I get SlimDX squared away I'll be sure to make the interfaces generic enough to write a wrapper easily.
SDL is a bit of an odd beast when it comes to managed code, and there isn't much support for it on the managed side of things (there's Tao.Sdl, but the fact that it's been unmaintained since 2009-2010 and has a number of unresolved issues is troubling to me). Unless you use Sdl_Mixer -- which I've had a number of timing issues with in my recent tests due to the tiny WAVs that Roton.Audio passes along -- you're pretty much reliant on dealing with raw streams of audio, rather than properly formed WAV data. I've been looking into OpenAl as well, but that might be overkill.

If Roton could stream audio to a sound output class, Lyon would be able to use just about any audio library in existence without much additional work, and it would probably work more reliably. My initial thought is reengineering Roton.Audio to fill buffers rather than playing audio on-the-fly.
Saxxon wrote:I just pushed an element bugfix (Monitor defaults were messed up) and the C# version of the frontend which is literally a direct port of the VB code to the GoogleCode repository. #BECOME MONITOR should work now.
Oh, speaking of game-related things, I did come across a bug, at least in the GoogleCode branch. If you mash ENTER before a dialog box completely comes up, Display.cs:SelectLine() gets called prematurely with an IndexOutOfRangeException. The easiest way to replicate it is to load up TOWN, go to the "scroll" on the first board, and mash the arrow that would make you touch the scroll and ENTER like a maniac. I've done it accidentally before, but the timing is very tight.

I just slapped a "if(LineIndex < 0) return;" above the first line, since the Keys.Enter case doesn't get the sanity check that the other keys in UpdateScroll() get.
Saxxon wrote:The memory layout project is actually in a separate repository, but that one exists solely for backup and version control. I'll be merging that one back into the trunk on GoogleCode sometime soon now that I have a proof-of-concept build.
Cool. I'm looking forward to seeing the code behind that project. :)
Saxxon wrote:Spectere, if you would like to contribute, I can give you commit access to the repository. I would be thrilled to work with others on this project, and if you can assist me in putting together something more multiplatform-friendly, I think it'll benefit the community greatly.
Sure, I'd be happy to help out in any way that I can. In that case, my first goal will be to get together a single package that runs on any platform with .NET or Mono installed without any modification or hassle. Audio is going to be the biggest hurdle at this point, but taking care of that should lead to a more efficient system for Windows as well.

It looks like VS2012 and VS2010 SP1 play nicely together (whoa, that's a first), so sharing SLN files shouldn't be an issue. Thank goodness.

User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: Lyon

Post by Saxxon »

Spectere wrote:If Roton could stream audio to a sound output class, Lyon would be able to use just about any audio library in existence without much additional work, and it would probably work more reliably. My initial thought is reengineering Roton.Audio to fill buffers rather than playing audio on-the-fly.
This can be done using the NAudio library for .NET, which I have been using in a number of other projects. (EDIT: On second thought, since I'm just generating the headers myself, I could probably just generate the wave data myself too.)
Spectere wrote:Oh, speaking of game-related things, I did come across a bug, at least in the GoogleCode branch. If you mash ENTER before a dialog box completely comes up, Display.cs:SelectLine() gets called prematurely with an IndexOutOfRangeException. The easiest way to replicate it is to load up TOWN, go to the "scroll" on the first board, and mash the arrow that would make you touch the scroll and ENTER like a maniac. I've done it accidentally before, but the timing is very tight.

I just slapped a "if(LineIndex < 0) return;" above the first line, since the Keys.Enter case doesn't get the sanity check that the other keys in UpdateScroll() get.
When I add commit access for you, it can be added in the main branch :)

Speaking of which, what's the account so I can add you? (You can PM it to me if you wish.)

Post Reply