z2

Smilymzx wrote:

bitbot wrote:Any luck? So does this mean you won't be posting updates here anymore? :(

Saxxon is still posting, Just less because of rebuilding in another language, Hopefully he takes my advice and port it to C or C++, Otherwise it will not be as wise.

(He was thinking of C#, A primarily Windows/Mac(Mono) only language. other than that, the portability is nonexistant)

Ok good. :)

Question for you Saxx.
Does (or will) Lyon support loading character sets? I'm thinking about making one- but is that even possible with SZZT?

bitbot wrote:Question for you Saxx.
Does (or will) Lyon support loading character sets? I'm thinking about making one- but is that even possible with SZZT?

The latest build already does. It will load them from .com files of the same filename.

I am implementing a completely different system for the HUD. I want to make it possible to use the default HUD but I don't want to make it manditory to use one. Currently, Roton directly accesses the Video interface supplied by the user's frontend:

Roton -> Video (client provided)

I'm implementing a class that is to reside in between:

Roton -> Display (internal) -> Video (client provided)

Additionally, I'm not tying a DOS-style character grid to Video anymore. Yes, you will still be limited to 256 char/color, since that is the general interface, but how this is presented onscreen doesn't need to be textmode. It would be just as easy to use graphics or something.

The Display class will take the output from Roton and format it for the screen: ZZT will slap a HUD on and SuperZZT will actually have scrolling supported by this class in its own limited window. I'm debating whether it would be a good idea to keep the game window so small as in the original engine, or to keep it large as it has been.

Can't it be both? I would argue to include the original screen size (and HUD) since standards are nice, and the 15 or so szzt games out there think that's the window size. I think title screens probably suffer from this worse than the actual games, but imagine (if you have played bitbot's game), that you made the torch illuminate further than normal. On the board with three different locations in it, you would be able to see the areas you are not supposed to see. SZZT (with only what, 30 something boards allowed?) needs to do this a lot, and the window is essentially the torch size.

Commodore wrote:Can't it be both? I would argue to include the original screen size (and HUD) since standards are nice, and the 15 or so szzt games out there think that's the window size. I think title screens probably suffer from this worse than the actual games, but imagine (if you have played bitbot's game), that you made the torch illuminate further than normal. On the board with three different locations in it, you would be able to see the areas you are not supposed to see. SZZT (with only what, 30 something boards allowed?) needs to do this a lot, and the window is essentially the torch size.

It's already set up for both. The debate is the default :)

Well then I think you know my position ;)

Saxxon wrote:

bitbot wrote:Question for you Saxx.
Does (or will) Lyon support loading character sets? I'm thinking about making one- but is that even possible with SZZT?

The latest build already does. It will load them from .com files of the same filename.

This is nice and automatic, but then you get games like banana quest with multiple files (or angelis where the two files don't share a name) A batch file handler might be not too much trouble. It could straight ignore commands like 'echo off' and file handling commands, and just pick out the names of .com and .zzt files, then two open dialogues, one to select the font, one to get the zzt file to use it (the listed directory filtering files based on the list generated from the .bat)

I mean, a fake prompt that handled the actual commands (like to show a menu, detect a keypress, show a message on quitting) would be ideal, but probably a nuisance to program.

Commodore wrote:Well then I think you know my position ;)

Saxxon wrote:

bitbot wrote:Question for you Saxx.
Does (or will) Lyon support loading character sets? I'm thinking about making one- but is that even possible with SZZT?

The latest build already does. It will load them from .com files of the same filename.

This is nice and automatic, but then you get games like banana quest with multiple files (or angelis where the two files don't share a name) A batch file handler might be not too much trouble. It could straight ignore commands like 'echo off' and file handling commands, and just pick out the names of .com and .zzt files, then two open dialogues, one to select the font, one to get the zzt file to use it (the listed directory filtering files based on the list generated from the .bat)

I mean, a fake prompt that handled the actual commands (like to show a menu, detect a keypress, show a message on quitting) would be ideal, but probably a nuisance to program.

I'm developing a solution for this. There are a lot of cool changes in store for Lyon. More on this later...

Great. I keep discovering nifty features in both Zap and Lyon. I look forward to seeing it all come together.

In regards to Lyon's SZZT viewport, I like the spaciousness of it, but the standard size is good enough. I think a large viewport in the editor is where it's needed most.

bitbot wrote:I think a large viewport in the editor is where it's needed most.

Commodore wrote:

bitbot wrote:I think a large viewport in the editor is where it's needed most.

I agree 100%. Here's the real dilemma: limit the editor to Ansi rendering or supplement it with windows controls? What's a good authentic/enhanced balance?

Don't say both. I don't feel like maintaining two user interfaces for the same editor..

If you mean separate GUI windows popping up for things like code and object properties, VS zzt style dialogue boxes, I'm in favor of the latter. Because you can have multiple sessions of a game, I wonder about multiple editor sessions: If each is able to pop up a window for code, I can see things getting messy. Mouse control should be like other char-based dos programs like edit and qbasic. Maybe there are separate keyboard-controlled and mouse-controlled cursors.

PS. If you do consider converting to C, Kevedit is open source...

This is also why I am thinking of Saxxon porting it to SDL, It supports porting from the DOS Textmode interface with *fonts, palettes, blinking and bright modes, and **column modes. Megazeux uses this

*with font sizes included, fonts supported up to 6-16 height
**with 80-40 columns modes

It is no problem if porting to SDL with the current features availible to Lyon so far, But this is not the 1st priority as far as development of Lyon goes...

Saxxon is still working on it, and I am greatful for what she has done so far.

ZZT started out as an editor after all, so it makes sense to stay true to that interface. As Commodore said, adding mouse support should supplement the keyboard- QB style. I might be biased here, but you should closely mimic KevEdit and build upon it. Your innovative edge is the integrated player, SZZT support, accurate ZZM playback, BMP import etc.

bitbot wrote:ZZT started out as an editor after all, so it makes sense to stay true to that interface. As Commodore said, adding mouse support should supplement the keyboard- QB style. I might be biased here, but you should closely mimic KevEdit and build upon it. Your innovative edge is the integrated player, SZZT support, accurate ZZM playback, BMP import etc.

Yeah.

The main goal is something complete that has good performance. When I can get something working in a language I know, I can start porting it to a language I'm only vaguely familiar with. SDL *will* be the target presentation platform, if I ever do port it to C.

I like Lyon so much. When I think that it runs most of my games flawlessly and even on a netbook AND i can hear basically what the pc speaker noises sound like (no pc speaker in netbooks) I think to myself that's so nice. I'm very happy with the lyon executable and the roton library.

It does not run my avarice.szt very well and kinda lags but in its defense there is a LOT going on in avarice .. I forget if a couple object when touched even crashed lyon, but that was cool.. Playing avarice is obvious in what doesn't work, but I believe any changing of the ... custom counter's name makes it crash, and it runs a little slow.. and the H button doesn't work on the title screen which advances the title screen's viewpoint in the cinematicey intro thing at your ease..

It would be nice to get a running copy of avarice that works perfect so I can post it at GT during a jam and give it another whirl.

I hope if you do get it rewritten it doesn't become the curse where you lose interest and abort. I like the project the way it is.. I've got one guy over in the other ug i'm in that is against anything written that relies on the net framework as it doesn't work for him so I'd spread the message. I think he doesn't use winders though.

We met in person too and that was pretty cool. But yeah I finally got a chance to check it out and for me well, it's an asset. I'd love to see scrolling graphics even though my latest title relied on the board edges not scrolling... Slightly more text file support would be nice too. like for instance I wanna rerelease Superugh.zip (http://hairypiano.com/Superugh.zip again in that other ug all posh and remade and slightly more vanilla, only part not working is the links to all the various text files. Otherwise everything else is ready.

Anyway good luck and happy trails.. I'll try to scroll back through this thread as I didn't reply sooner because I wanted to be up to date on the thread first but thought I'd say hi first.