Menu
▾
▴
jzip-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Jason C P. <jp...@ch...> - 2000-07-15 14:57:03
|
Hi, Since 7/17 is rapidly approaching, I was wondering how everyone was doing on making their wxWindows front-ends. I haven't had as much time as I hoped but I did do quite a bit of work. Unfortunately, I feel that I approached it wrong and have since started again. I was just wondering if things were going peachy for everyone else or not. Later, Jay ---- Jason C Penney (jp...@ch...) Xarton Dragon -=<UDIC>=- <http://www.chelmsford.com/home/jpenney/> "A straight line may be the shortest distance between two points, but it is by no means the most interesting." --The Doctor |
|
From: Jason C P. <jp...@ch...> - 2000-07-06 22:07:26
|
Hi, This is probably ahead of it's time, but I thought I'd through it out. There's a bit of history to go with it. The V6 Screen Model is well defined... in at least two different ways. Much discussion on the Z-Machine list about how to standardize this took place. While this was going on Graham proposed V9 (V8 + new stuff) and falling off of this came V10 (V6 + minor changes + V9). Nothing came of this later discussion, probably because of Glk/Glux. Anyhow, the V6 issue was never standardized. What follows is my proposal for a header extension based on the V6 discussions, and then the few changes I proposed for V10. (I'm going to get a reputation for being long winded here, aren't I?) I just want to bring it up now, because if everything goes correctly and we have a wonderful WxJzip+V6 this is going to come up. All these ideas were designed around not breaking what already exists. [-------------------------------------------------------------------] Some Proposal or Other About V6 Machine Capabilities Take 4 Draft 1 Jason C. Penney After much thought and discussion this time around I've thrown out the new machine number and gone for the header extension, probably using Word 4. I've also tried to handle some of the issues mentioned in Section 11 of the Blorb Spec (1.0). When reading this, remember that I'm just trying to draft up a proposal. If an idea is crap, let's fix it. Proposed format of header extension ----------------------------------- Hex Contents === ======== 0 Extension honored? 1 Supports music? 2 Multiple sound support? 3 Full font style combination support? 4 Supports 3-OP @set_colour? 5 Provides Amiga text pallette? 6 Each window has own colour pair? 7 Supports multiple text colours? 8 9 A B C D E Proposed information in header extension ---------------------------------------- * Extension honored? This bit should be set if the interpreter honors the extension by filling out the rest of the header extension. If it is not set then game files should rely on the interpreter number to signify what features are available. * Supports music? This bit should be set if the interpreter can play music. (see Blorb Spec, 11) * Multiple sound support? This bit should be set if the interpreter can play multiple sounds at once. If this is so, the interpreter should support the following extended syntax for @sound_effect. @sound_effect number 3 This should stop the sound 'number' if it was currently playing. If this bit is not set, then the interpreter follows what is currently in the ZSpec. * Full font style combination support? If this bit is set the interpreter should follow the "Ideal" model set out by the ZSpec, "all text styles should be available for each font (for instance, Courier bold should be obtainable) except that font 3 need only be available in Roman and Reverse Video". If the interpreter is unable to fully comply with this the bit should be left unset, and game authors should take this to mean that they can't count on anything in this respect (which is how it is currently). [NOTE: the above set of info would probably be useful for any V5/V8 games that wish to use sound as well] * Supports 3-OP @set_colour? This bit should be set if the interpreter supports the 3-OP version of @set_colour. * Provides Amiga text pallette? This bit should be set if the interpreter provides the Amiga V6 text pallette (i.e. colours 10-12). * Each window has own colour pair? This bit should be set if the interpreter allows each window to have its own distinct colour pair. If so @erase_window should use the windows background colour when erasing. If not @erase_window will use the background colour stored in the header. * Supports multiple text colours? this bit should be set if the interpreter allows multiple text colours to be displayed on screen. If it is not set @set_colour should change all text visible on the screen (as the Amiga interpreter does now). [NOTE: That leaves 7 bits. Maybe 2 or 3 could be used to signify the colour depth the interpreter provides in some way.] What Dos Frotz would need to do to support this. =============================================== (provided as an example, being that it is the interpreter I have the most experience with) For Frotz to support this with no changes to the current screen models it provides it would have to check if the header extension is present, and if so it should do the following: In MCGA mode: Set bits 0,3,4,6 and 7 In Amiga mode: Set bits 0,3,4, and 5 [NOTE: I'm 99% certain it should set bit 3...] [------------------------------------------------------------------] A bit less relevant maybe, but here was what this became in V10. It does show how the primary idea was to throw out the Amiga model. From: "Jason C Penney" <jp...@ch...> To: Z-Machine Mailing List <z-m...@gm...> Date sent: Tue, 19 Jan 1999 20:30:42 -0500 Subject: [z-machine] V10 proposals... Send reply to: Jason C Penney <jp...@ch...> Priority: normal Hello again, First I'd like to address Gunther's point about the different machine modes. The discussions about this before all pretty much boiled down the the following Long ago Andrew Plotkin asked: > Now, if we ignore that one display mode [Amiga Mode] -- with its > two-color limit, etc -- can we write to the Z-Spec and not worry > about machine numbers any more? And I replied: > More or less, everything becomes peachy. Now on with the show Minor additions to V6 I'd like to see in V10 as a result of all the hashing about that went on before... 1) Bit 6 of 'flags 1' is undefined in V4+ Define it to be a 'Full font style combination support?' flag. If this bit is set the interpreter should follow the "Ideal" model set out by the ZSpec, "all text styles should be available for each font (for instance, Courier bold should be obtainable) except that font 3 need only be available in Roman and Reverse Video". If the interpreter is unable to fully comply with this the bit should be left unset, and game authors should take this to mean that they can't count on anything in this respect (which is how it is currently). 2) add a bit to 'flags 2'. If the game wants to use music it should set this bit, the interpreter should clear it if it can't play music. (If proposal 4 is adopted, this should tie in with it, if not it still stands on it's own to say that files identified as music in a blorb file can still be played by the interpreter) (see Blorb Spec, 11) 3) extend @sound_effect: @sound_effect n 3 with n > 0 ...stops sound_effect #n only @sound_effect 0 3 ...stops all sound effects This would allow multiple sound effects (if the interpreter supports this there would need to be a way to signal the this as well, maybe another header bit). 4) Add a separate opcode for music (@sound_music?) It would be the same, or very similar to @sound_effect, but allows the music system of the interpreter to work independently of the sound effect system. (interpreters need only support this opcode if they set the 'can play music flag', otherwise they should just treat it as a nop or something, I think.) That's about it, Jay [--------------------------------------------------------------] And again... that's about it. Thanks for reading Jay ---- Jason C Penney (jp...@ch...) Xarton Dragon -=<UDIC>=- <http://www.chelmsford.com/home/jpenney/> "A straight line may be the shortest distance between two points, but it is by no means the most interesting." --The Doctor |
|
From: J. H. <jh...@fr...> - 2000-07-06 19:37:00
|
okay, lets see if I've fixed procmail. -- John Holder (jh...@fr...) http://www.frii.com/~jholder/ |
|
From: J. H. <jh...@fr...> - 2000-07-06 19:32:43
|
more procmail hacking. -- John Holder (jh...@fr...) http://www.frii.com/~jholder/ |
|
From: J. H. <jh...@fr...> - 2000-07-06 19:28:21
|
Just testing one of my procmail recipes for storing the list. ignore. -- John Holder (jh...@fr...) http://www.frii.com/~jholder/ |
|
From: J. H. <jh...@fr...> - 2000-07-06 19:26:23
|
Here is what Jzip lacks in the V6 department... The following opcodes need to be added (a) or modified(m) to enable V6 zcode: a draw_picture m erase_line a erase_picture a get_wind_prop a make_menu a mouse_window a move_window m output_stream a picture_data a picture_table a pop_stack a print_form a pull_stack a push_stack a put_wind_prop a read_mouse a scroll_window m set_colour m set_cursor a set_margins a window_size a window_style The stuff that deals with windows will need some windowing data structures added to the core of zmachine. It would be nice (but might not be possible) to not have to push much implementation of window code into the frontend layer. -- John Holder (jh...@fr...) http://www.frii.com/~jholder/ |
|
From: J. H. <jh...@fr...> - 2000-07-05 15:26:37
|
I;ve updated the source tree so the code in interpreter dir will compile will no warning messages from VC6. John -- John Holder (jh...@fr...) http://www.frii.com/~jholder/ |
|
From: J. H. <jh...@fr...> - 2000-07-05 14:14:50
|
Jason C Penney (jp...@ch...) wrote on Tue, Jul 04, 2000 at 09:22:43AM -0400: > > --Introduction time! > > My turn! Thanks for the nice intro... Ironically, the large systems I was admining and doing a tiny bit of development on at Jones Intercable was as a subcontractor for Sun, on lots of large Sun 2000 and UltraSparc boxes... [snip] > A certain John Holder was the first person to see this besides me.... > (Hope you don't mind John) No, and thanks for no digs on me never getting around to a lot of the things I wanted to... (grin) > As far as V6 goes, how do we handle the stuff that's already there? > The memory access routines and such? A lot of the standard opcodes > change behavior in V6 as well. There is currently _no_ support for V6 options in the exiting opcodes, and the V6 only opcodes aren't implemented yet. Whee! In other words, we need to print a copy of the spec, ihghlight every occurence of "... in V6, this happens..." and make it so. > Before I get well ahead of myself... I'm not sure I'm doing things > quite right, so let me check with you guys. I should do a checkout > of everything to get a local copy, right? Yep. > Is Jzip set up to build out of this directory structure? > I want to make sure I can make the > dumb version before I do anything else, so for right now that's the > hurdle. I know I CAN do it (copy the files into one directory), but > I want to make sure I'm doing the it the right way. Any > pointers/instructions would be greatly appreciated. I need to fix the makefiles. I'll update the makes for termcap UNIX, curses, and dumbio to build from the appropriate frontend directory. In the meantime, copy everything from the frontend dir to the interpreter dir, edit the Makefile if necessary, and type make. (UNIX) In VC, it is not necessary to move source. Do "file->new" and pick add new Windows console app (eventually it will be just windows app). Assuming everything is under D:\Jzip, set the dir to D:\jzip\win32\ and the project name to dumbio. Then tell VC to create an empty project. Add the source to the project by right clicking on the "Source files" folder in the workspace (under the "Fileview" tab) Select all the .c files in the interpreter dir except jzexe.c and ckifzs.c and select the file in the dumbio dir. While the root node of the dumbio tree is selected in workspace, go to project settings. Click on the C/C++ tab. In the Category dropdown, Select "preprocessor" and add "LOUSY_RANDOM" to the "Preprocessor Definitions" edit box. Under the "Link" tab, change the executable name to "jzip.exe". Then hit F7 to build. That should do it! (Note: we make want to check in a set of VC .dsp project files into a win32 tree to avoid this silliness - although VC 5 might not like VC6 project files. John -- John Holder (jh...@fr...) http://www.frii.com/~jholder/ |
|
From: Jason C P. <jp...@ch...> - 2000-07-04 13:27:44
|
Hi guys, Sorry for the delay in the reply... I went out and bought a new hard drive and spent the last few days moving stuff over and setting up VC++ 5, wxWindows, WinCVS and ssh. J. Holder sent a message across the ether on 29 Jun 2000, (8:51) stating: > > Do you think it will compile under VC5 (I found it, that's what I > > have)? If so I'll try to get another hard drive and work on that > > until my linux box is up. > > VC5 should also work. Chances are one of the two of us will have to > rebuild the wxWindows distribution for MSWin to make it go. I've pulled down and built wxWindows under VC5. It builds the samples ok, so I seem all right there. > --Introduction time! My turn! I'm 24, and live with my long time girlfriend, Denise. I'm big fan of audio drama (from Old Time Radio, to much more recent stuff). I spend some of my time doing audio restoration to old episodes of "The Shadow". I have a BS in Computer Science. I fell right out of college into a job with Sun Microsystems. I used to work in QA for Solaris Software (formerly SunSoft). I now work in the software QA group for Network Storage (still at Sun). Here's a bit of my IF/Z-Machine history... I originally played adventure on an old Wang system when my mother took me to work one time. I was addicted. I never had a computer when any of the Infocom games where out, but I played some of them at other peoples houses. I got a used 8088 around the time Lost Treasures came out. I was fascinated with Zork Zero. When I got to college it took me about a week to find usenet, and from there raif and rgif. All the buzz was about some game "Curses". From there I stumbled across the Z-Machine. I devowered the ZSpec. I stared playing with Inform (this was around 95). My goal right off the bat was to make V6 work. I started porting Adventure to the Arthur dos interpreter. Found bugs in Inform, specs changed, Frotz appeared. Serious work began on what is now V6Lib. The Blorb spec appeared. I got Inform to compile a playable game using the pics from Zork0 to make a compass rose status bar (around 97). A certain John Holder was the first person to see this besides me.... (Hope you don't mind John) --------------------------------------------------- Date sent: Wed, 10 Sep 1997 15:24:50 -0600 From: jh...@fr... (J. Holder) To: jp...@ch... Subject: Re: Beyond Zork-y games Jason C Penney writes: > Hi, > > Just curious if you go a chance to take a look at the test file or not. > If so, what do you think? Yup. Looks pretty straghtforward - I'm now eagerly anticipating the library! Now if we could only get some blorb-capable interpreters out... (looks guilty) I've been neglecting Jzip for WAY too long... -------------------------------------------------------------------- I put out a release of V6Lib, and a few more, and advent.z6. And then the waiting game began for me. Blorb Frotz was a serious project for a while. I did some work to help Stephan port Frotz to djgpp (which he duplicated because he fell behind in his email... d'oh!). Then it just stopped.... HTML-TADS appeared, Glk/Glux/Gluxe popped up. I kept working on V6Lib, but it slowed down since I was pretty much out of things I could do without a modern interpreter. Recently I got on the ifMud (which I used to frequent almost daily, and now sadly I log in every six months) and found that quite a few people there wanted to know what was up with V6Lib. I wondered myself. :-) While doing a bit of looking around at options to build my own Zterp (a doomed concept at best), I stumbled across jzip.sourceforge.net, and here I am! Whew! Sorry about all that... you still awake? > Back to business - I've added some tasks in the Project/Task manager. > The V6 task will be owned by Jay, I will support. I own the Unicode > task. We all share the wxWindows task. Subtasks for V6 should be > created by Jay (if you need any). The initial wxWindows task is one > we should each implement. As far as V6 goes, how do we handle the stuff that's already there? The memory access routines and such? A lot of the standard opcodes change behavior in V6 as well. Before I get well ahead of myself... I'm not sure I'm doing things quite right, so let me check with you guys. I should do a checkout of everything to get a local copy, right? Is Jzip set up to build out of this directory structure? I want to make sure I can make the dumb version before I do anything else, so for right now that's the hurdle. I know I CAN do it (copy the files into one directory), but I want to make sure I'm doing the it the right way. Any pointers/instructions would be greatly appreciated. Jay Penney ---- Jason C Penney (jp...@ch...) Xarton Dragon -=<UDIC>=- <http://www.chelmsford.com/home/jpenney/> "A straight line may be the shortest distance between two points, but it is by no means the most interesting." --The Doctor |
|
From: J. H. <jh...@fr...> - 2000-06-30 14:06:33
|
Paual, As you can see, I set up a mailing list. Probably overkill, but it looks cool. If anything about how this list is configured annoys you, let me know, I can probably change it. John -- John Holder (jh...@fr...) http://www.frii.com/~jholder/ <jholder> do you like FreeBSD? <hal> I need to get the ISDN line running so that I will tell it to pass over me and replace my SuSE box with FreeBSD. |
