Page 2 of 38

Posted: Fri Jun 17, 2011 11:00 pm
by Saxxon
Smilymzx wrote:We might have to keep the DOS Versions, for nostalgic and archival purposes, This should also NOT be considered a clone, It's a well-done remake of (Super)ZZT, You got my approval on that.
I don't want to replace ZZT. This is an experimental alternative. :)
Smilymzx wrote:FreeBasic is for Linux/Windows 64 and 32bit systems, Freebasic should also be portable to other systems such as any newer Unixes. It is under GNU GPL just so you know.
Another BASIC language? Probably not. I'd like to work with Dr_Dos to get it implemented in Python. If that's not going to work, maybe I'd do Java by myself.

Posted: Sun Jun 19, 2011 12:24 am
by Saxxon
Found a bug which was making CATCAT.ZZT do strange things. Turns out there's a 1 cycle delay after an object displays a scroll. Going to fix that tonight.

Also, the player's background color will actually turn light gray when hit by an enemy or projectile. The player's background color will also behave correctly on empties in Super ZZT.

Fixed a bug that caused SuperZZT objects to get stuck when given a number with /I. Found this one with the SZZT Encyclopedia title board.

Posted: Tue Jun 21, 2011 4:12 am
by Saxxon
- Fixed a SZZT passage bug.
- Added proper web tile drawing.
- Fixed a bug that caused some binds to behave strangely. As a result, the system of deleting and performing garbage collection of objects has been rewritten entirely.

Posted: Tue Jun 21, 2011 7:25 pm
by Saxxon
Alright, this one's got me really stumped. In Mission:Enigma, the gate opens up differently in ZZT than in Lyon. Strangely, if you follow the code in the gate objects it should actually do what Lyon does. But it doesn't, the left gate object skips over one of the movements in the original engine.

ZZT:
Image

Lyon:
Image

I'm thinking the extra movement was placed in there as a hack to get the object to behave as it should in ZZT when the game was written. While it shows up every time I can't seem to figure out why.

More fixes:
- Player won't move when interacting with a scroll if a scroll must be shown on the screen.
- Centipedes shouldn't freeze the program anymore under certain conditions.
- Better screen updates in Super ZZT games.

Posted: Wed Jun 22, 2011 2:05 am
by Commodore
that's weird. wonder if it has to do with the "#put s green" or the fact that the objects share a name. The lower gate pieces seem to spam the :gate message too.

Posted: Wed Jun 22, 2011 2:12 am
by Saxxon
Commodore wrote:that's weird. wonder if it has to do with the "#put s green" or the fact that the objects share a name. The lower gate pieces seem to spam the :gate message too.
I took the original code and added a few lines to it. First movement gives 1 gem, second 2 gems, third 4 gems, fourth 8 gems, and fifth 16 gems. Then I could find which lines were skipped. A strange result happened, after execution in ZZT it gave 13 gems (1+4+8). In Lyon it gave the expected 31 gems (1+2+4+8+16).

Posted: Wed Jun 22, 2011 2:36 am
by Commodore
This gets weirder. If you grab the different gate objects, delete and re-plot them (changing their stat index) you get all sorts of different outcomes for the gate going up.

Posted: Wed Jun 22, 2011 5:18 am
by Saxxon
Commodore wrote:This gets weirder. If you grab the different gate objects, delete and re-plot them (changing their stat index) you get all sorts of different outcomes for the gate going up.
Nice find. Might have something to do with objects being deleted.

EDIT: I see what's going on, looked at a stack trace. Object pointer is pushed onto stack during execution of ExecuteOOP. That function calls PlotTile on the target tile during #PUT. PlotTile calls HarmThing before setting the new tile's properties. HarmThing calls RemoveThing if it's a stat object (and if it's object #0, HarmThing deducts 10 health, etc). RemoveThing, upon completion and if the removed object's index is not the final one, will move all objects in the array back to remove any gaps in the array. When it gets back to ExecuteOOP, the pointer has not been changed, and it is actually referencing a completely different object when it goes to write the CurrentInstruction.

To implement this, it would require a large rewrite to the object garbage collection system. The way it is in ZZT is an ugly side effect of how it uses pointers.

Should this bug be reproduced in Lyon or should code run as one would expect in normal conditions (which is how it is coded now)?

Posted: Wed Jun 22, 2011 12:38 pm
by Commodore
I don't think it's too important, what could you do with it, it's not a useful bug. On the other hand...

What's more important for me is, how do I avoid it as a zzt programmer?

Posted: Wed Jun 22, 2011 5:27 pm
by Saxxon
Commodore wrote:I don't think it's too important, what could you do with it, it's not a useful bug. On the other hand...

What's more important for me is, how do I avoid it as a zzt programmer?
Make the objects you are deleting have a higher object #. Objects that must work correctly and don't get deleted (for example main parts of an engine) should have the lower # because they won't be affected by shifts in the object array.

Posted: Wed Jun 22, 2011 8:42 pm
by Saxxon
I've drawn out what needs to be done to implement the way ZZT handles object cleanup. If not implementing it seriously breaks any games out there, I will consider doing the code change.

Furthermore, I believe Lyon is far along enough to merge with Zap. Will release one more version before starting that project.

Posted: Wed Jun 22, 2011 8:44 pm
by Commodore
same with something like #change lion empty?

Posted: Wed Jun 22, 2011 11:20 pm
by Saxxon
Commodore wrote:same with something like #change lion empty?
Anything that deletes stat objects.

Also, having fun with MDI layout in preparation for the merge. It can load up as many worlds as your computer can handle. Thinking about making it easy to do concurrent editing and gameplay for fast testing.
Image

Posted: Thu Jun 23, 2011 3:18 pm
by Saxxon
- Added saving games and worlds. It will automatically pick which extension to use based on the LOCKED flag in the world, but you can always change the extension when saving anyway. Not like people really lock worlds with this anymore.
- Multiple worlds can be loaded at a time. When clicking File-Save, it will work with the currently selected window. Only the focused window will be processed. Unfocused windows are suspended.
- CTRL+Tab will switch between windows. Just like any other MDI setup, when you maximize one window, they will all cycle maximized.
- Things and Commands will be shown in the lower-right corner. This should make it easy to check the load your code is putting on the engine:
Image

Posted: Thu Jun 23, 2011 6:43 pm
by Saxxon
Build 2 is up. Demo recording is temporarily disabled while I work on getting everything together. New and Editor stuff appears in the File menu, but they are placeholders for now.

Bug reports welcome. :)