Commodore wrote:Just a quick thought I had about an editor was that you could make toolkits useful again if you allowed the buffer to carry over or could somehow link buffers between open editor windows.
I thought about this. Not sure how I'd be able to implement it but I'll definitely keep it in mind.
Good news, DirectDraw support is now in. Performance increase across all platforms. A side effect of this however is that graphics interpolation doesn't seem to work. For that I believe they will force me to use Direct3D. Since that's a whole other world of its own, I'll keep things simple and leave it at DirectDraw for now.
I won't release a new executable just yet as there are a couple visual bugs in the DirectDraw implementation that I need to fix first. I'm only just learning this API :)
Commodore wrote:The drum sound effects sound a little weird, especially when played in rapid succession.
When recording the drum effects, I had to slow the game down in DosBOX. What seemed to be happening was the sound effects are based on the CPU clock, so they are going to be all clicks at a high rate. These sounds were recorded between 2000-3000 cycles and I picked the ones that sounded the best. I considered the possibility of substituting drum sounds if you wanted something different. Right now they are actually built into the executable as recorded waves. If you have drum sounds that sound better, please send them my way :)
Commodore wrote:Also maybe USB game-pad support?
I am familiar with the WinAPI method of polling for joysticks, but for this I think it would be best if I studied DirectInput. This way you could use whatever input device you wanted. One thing I dislike a lot about most emulators/simulators is their poor support for mapping controllers - rest assured I'll make it flexible.
Fixed the #throwstar bug. It was a bug in the OOP code which was adding the vector twice, causing all stars to be thrown one square further than usual.
Fixed a bug in #take/#give. When the type is not recognized, the command needed to return successful. This should fix the instant deaths in Death. Incidentally, there is a bug in the game's OOP code itself if you look at the rats on the board called "Four" which would actually make it impossible to take any damage at all.
Fixed the sound generator, the square waves being generated were not quite being generated completely - on generation of a wave with an odd byte cycle, one sample wasn't being set.
Fixed a bug in the menus. For some reason I had to rebuild every single menu and item in the menu bar because of some corruption in the project's settings.
Fixed all the visual bugs in the DirectDraw renderer, so I think a release might be ready today. The difference in performance is pretty big.
New build ready. This includes DirectDraw support and it is enabled by default. You can enable/disable it in the Renderer menu at the top. I will find a better way to implement this option, but I need it up front for easier debugging. Changing this option with a game open does not change renderers. If you want to use DirectDraw, you need to have it enabled BEFORE opening a game. Note that DirectDraw does not support smoothing the image.
I want to add support for ZIP archives but it looks like I might not be able to do this without the assistance of a third party library. I do not want to make people install anything special to get this working beyond what's already needed (DirectX9 and .NET 2.0). The benefit to keeping games in a ZIP archive is that their original filename can be preserved but the archive can be renamed. This will keep files that belong to the same game together.
I think being able to stream ZZT sessions would be cool. Then you could watch someone else's stream. Maybe even compete. Considering the random number generator is rigged to be predictably random (if that makes sense) all that'd need to be streamed is the sequence of movements. You'd need the original ZZT world files of course.
I would really like to be able to integrate with zzt.org in some way but it's not my server and I don't think it would be reasonable to expect that I could simply bypass everything else the site has to offer.
The new build is noticeably peppier.
ZIP would be good, but a clean exe may be preferred.
Would it be too much to request an option to disable the status bar? (For those of us with tiny screens.)
bitbot wrote:The new build is noticeably peppier.
ZIP would be good, but a clean exe may be preferred.
Would it be too much to request an option to disable the status bar? (For those of us with tiny screens.)
I could certainly implement that. The status bar is actually broken anyway - it's not even used by the editor due to a bug I had with the controls on every window (damn you VS2010).
In keeping with the "clean exe" idea I might just reinvent the wheel and write up a light ZIP processing class. The framework has Deflate and BZIP built in but neither of these are used in the typical PKWare implementation since there are better compression methods out there. If I needed to implement adding to the archive I could just abuse Deflate - maybe for saving high scores or something.
Saxxon wrote:I would really like to be able to integrate with zzt.org in some way but it's not my server and I don't think it would be reasonable to expect that I could simply bypass everything else the site has to offer.
Saxxon wrote:I would really like to be able to integrate with zzt.org in some way but it's not my server and I don't think it would be reasonable to expect that I could simply bypass everything else the site has to offer.
What kind of integration were you thinking?
ZZT worlds on demand. You'd be able to pull up a complete list of available worlds and download whichever one you want to play. It would of course only download ones that weren't present on the hard drive. Essentially it would be a ZZT world browser. I thought about replacing the "Open World" dialog with something like this. I'd do this after support for opening ZIP archives. Maybe even get more information like rating.
It's more or less a feature that aims to make getting into ZZT a lot easier for someone who's never heard of it.
I'm sure several of the worlds are old enough to be PKzipped, is it any different from the default "zip" that windows does? Anyway, that's a great idea.
Also I was thinking of macros, so you could program ?+i or ?zap as a single key/joypad press.
Commodore wrote:I'm sure several of the worlds are old enough to be PKzipped, is it any different from the default "zip" that windows does? Anyway, that's a great idea.
Also I was thinking of macros, so you could program ?+i or ?zap as a single key/joypad press.
Windows has the same kind of ZIP but I'm sure the ability to compress and decompress these in the .NET framework doesn't exist for licensing reasons.
I had the ?+i macro functionality in the older version of Lyon, but I wanted to make it so that it could be customized. I'm actually going to implement cheats in the Input interface so that you don't interact with Roton itself to input these - this would make it easier to have cheat entry in demo playback since demos are a special class of Input.
Implemented some keyboard shortcuts. F12 hides the menu bar - the game will fully maximize to the Lyon window now. Alt+Enter will maximize/restore the Lyon window. Ctrl+Enter will maximize/restore the current game window.
Fixed the message display. ZZT puts the message one character to the right of where it's supposed to be for some reason. Since some boards actually rely on the horizontal alignment of this message, I have put in a new parameter that allows shifting the placement of the message on a per-engine basis (Super ZZT won't have this - but it displays messages differently than the original engine anyway).
Fixed some memory holes caused by the use of DirectX. Since it is managed, these resources are freed anyway over time. However, it doesn't hurt to help the system along by telling it "hey I'm done with this object".
I am implementing demos that can be recorded and played back. I will also consider making it so that you have the option of exporting a demo whenever Lyon crashes out of the game. This way I can reproduce it with no effort. The way this will work in the Roton engine is, you will create your Input class then create a DemoRecorder class that wraps it. Then you simply use DemoRecorder as your primary input and it will record all the needed information. When you want to play it back, you create a DemoInput class and slap it on the Environment. Roton takes care of the rest.
Demo recording and playback is working beautifully. I didn't even have to change any code to make it work, just write some demo classes that implement the Roton Input class. Cheats are also recorded, but you don't get to see them actually being typed in. The cheat sound still plays however.
Until I get a working cheat mapping interface in, I'm going to map ?+i to I. This key will actually work as a toggle. If you press it, it will set/unset the flag as necessary (if there's room for it).
