If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Thanks for all the vids. I posted a few comments and replies on phreakindee's in regards to the upcoming 1.6 release and how it effects the AI. Compiling the changelog right now, here's a preview of what's different in the version I'm HOPING to go public with wednesday... Friday at the latest.

Added MT32/GM/Midi support
Requires the MIDI device to have a 24 step pitch bend range or allow setting via RPN -- Which "Microsoft GS Wavetable" does not... This is still in the early development stages and doesn't sound all that great yet -- but it shows promise. Will be better when/if I design custom program changes for the MT-32 instead of using the built-in sound banks.

Better EGA and VGA support
VGA now uses BIOS scanline set, works properly on pretty much everything!
EGA sets misc register properly, a few changes to the logic order of loading done as well.

"infinite fruit" bugfix
Added counter of how many have been shown

Fixed AI bugs
random for ghost turn was ignored
random for ignore chase was always taken
death during final 'chase' resumed as 'always scatter' instead of a 250 iteration scatter followed by resuming the chase. Fixing this bug revealed the Final Chase Update Bug.

*** NOTE *** AI bug fixes may have increased difficulty

Final Chase Update Bug
Fixed behavior update procedure being called every timer tick once the 'final chase' was reached. This got rid of late game 'slowdowns' on slower systems... (and sometimes it even hit faster ones!)

Improved sound on/off handling
Can now turn sound off mid-theme and during longer sfx

Better dividing of tasks between audio timer ticks
Should lower CPU speed requirements even further

Removed many FOR, WHILE and REPEAT for recursive object calls
Speedup, lower memory use and simpler logic flow

Rewrote many library functions in ASM
speedup, smaller exe size

Stopped passing sprite pointer on every call
now handled by global pointer "tileSource"
speedup, less stack use

Renamed many procedures and variables
Code cleanup, make it easier to find things

Renamed all data files to .DAT (no more .FNT or .TDT)
Actually allowed a bit of code reduction as now all .DAT are handled by one handler object (or inherit from it) -- and it's easier to keep track of when copying files to build the distro. (or making a minimalist floppy)

Abandoned PC/JR and Tandy specific video code
Due to bugfixes and better understanding of the CGA implementation on both platforms, the code to try and use the 160x200 video mode is no longer required.

So... basically the past 9 months since the last release weren't completely wasted -- AND I've got two other games in the works, one nearing completion -- the other being... well... It's probably going to have an AT as the minimum spec despite using this same video mode. I don't know why, but I'm really digging how the 160x100 graphics look; It's probably the Atari 400/800/5200 fan in me on that, since PMODE4 was 128x96... and some of the best games for said platform were done using pmode 4 with palette tricks.

Developing this next version has been a bit of a trip -- when I started adding the MIDI code and cleaning up the AI code, the .EXE grew upwards quickly.. 72k...80k... 92k... until I realized it would no longer run on a 128k DOS 2.11 system -- unacceptable. After making all the code tweaks and converting large sections of the library units to assembler I've actually gotten the final .EXE for this version an entire K smaller than previous versions -- and it fits into the same size stack/heap allocation giving it a memory footprint of exactly 65k... so even a 128k DOS 3.2 system has a decent chance of being able to run this new version I'm polishing up for release.

From time to time the accessibility of a website must be refreshed with the blood of owners and designers. It is its natural manure.CUTCODEDOWN.COM

Not sure, as I said in the comments to your vid I tested on a SB 1.0 -- so I'm not sure what would be different enough to cause problems. It's a very poorly documented device so it's not too suprising there may be issues between hardware implementations. If I have time I'll go back over the docs and compare against my code.

-- edit -- it was working fine on my XT clone, but I plugged the 1.0 into my AMD 386/40 and it's a no-go. (thought I'd check a similar processor to see if that's it)... I'm using the 16 bit port out routines -- wondering if the register isn't getting set before the data. I'm gonna redo the CMS reset routine using 8 bit port outs and inc/dec DX to see if that makes a difference.

From time to time the accessibility of a website must be refreshed with the blood of owners and designers. It is its natural manure.CUTCODEDOWN.COM

Can you make a tutorial on how you did your own in-browser DOSBOX, with the lovely Tandy CM-11 monitor around it?

All that *.JAR file stuff, and the details on how to get the java Dosbox going, I have not seen a decent instruction manual on how to do it.

Yeah, getting the screen facade around the display would be nice to know how to do too, but knowing how to take something for DOS and get it in a browser, would be helpful, if explained with a bit more detail.

I did go to the SourceForge page for the jDOSBOX, and the instructions were very scant, scarce, whatever.

Gave you a shout out for asking, with a backlink here. Covers pretty much all you need to know to get the current (0.74.25) jDOSBox up and running on a website.

Originally Posted by kiyotewolf

, with the lovely Tandy CM-11 monitor around it?

That's actually a bit more complex as I built that ENTIRELY with CSS3 properties... so unless you know HTML4 and CSS3, any explanation would be ... difficult to understand. Mostly it's just a bunch of DIV using border-radius and box-shadow, with the -moz and -webkit equivalents to make sure FF and Safari/Chrome behave.

Originally Posted by kiyotewolf

How do you even make a *.JAR file anyways?

That's the real laugh, they're just .ZIP files with a different extension on them -- and a special directory structure for running JAVA code. Since we don't need to run JAVA code inside our game archive, the second file can just be a plain ZIP.

<param name="archive" value="jdosbox_applet.jar,jdos.zip" />

First file sent to it is a JAR, containing the jDOSBox code... the second file? A plain .zip with a /jdos subdirectory. In that subdirectory you have your dosbox.conf file and the virtual disk image. Pretty simple.

Oh, and I know I'm finally in the right place when someone recognizes the model display I patterned the object wrapper after. It does just SCREAM TANDY, doesn't it?

From time to time the accessibility of a website must be refreshed with the blood of owners and designers. It is its natural manure.CUTCODEDOWN.COM

I dug up this forum after running your other test to actually check out this game like I was going to. Ran into some interesting issues though. The screens flash back and forth between weird and weird & messed up:

Did you download an older version or somethi... wait, that is a REALLY old version, like from a year ago (notice the lack of a high score box on the menu page)...

That's like version 1.2 or something, from before I fixed the PCJr not turning the blink bit off the same way a cga or tandy does. Download the latest version (1.6) as that bug has been fixed for six or seven months now.

The main page for version 1.3 or higher has a high score list center of the menu:
click for larger

Added MT32/GM/Midi support
Requires the MIDI device to have a 24 step pitch bend range or allow setting via RPN -- Which "Microsoft GS Wavetable" does not... This is still in the early development stages and doesn't sound all that great yet -- but it shows promise. Will be better when/if I design custom program changes for the MT-32 instead of using the built-in sound banks.

I can't get the GM support to work at all. I have a PMMX system with a crappy Soundblaster clone with a clone of a Yamaha DB60XG synth attached to its Waveblaster port. GM usually works out of the box (and sounds many times better than Ad Lib) on this system, but when I try to run "paku /gm", I get "Runtime error 002 at 05DD:0089". I get the same error with "paku /gm:330" (which is the correct address for the MPU-401 interface).

By the way, I absolutely love the game itself. Even though I don't have any hardware from the era, I'm amazed that this thing works on the 5150, and I'm glad it also works on later hardware. Not to mention that it is an awesome Pac-Man clone.

I can't get the GM support to work at all. I have a PMMX system with a crappy Soundblaster clone with a clone of a Yamaha DB60XG synth attached to its Waveblaster port. GM usually works out of the box (and sounds many times better than Ad Lib) on this system, but when I try to run "paku /gm", I get "Runtime error 002 at 05DD:0089". I get the same error with "paku /gm:330" (which is the correct address for the MPU-401 interface).

Unless I'm going blind, that's the right filename... the file is there... but it's throwing a file not found?!?

-- edit --- I changed all files to use the .DAT extension and my 'universal' data loader now adds it automatically -- but 'sound' was still trying to add .dat itself. The string maxlength is 12, so the .DAT is being chopped off all the other files, but GM is ending up PAT_GM.DAT.D -- DOH!

For now use /MIDI instead, and I'll add that to the list of changes for 1.7

Last edited by deathshadow; December 23rd, 2011 at 06:53 AM.

From time to time the accessibility of a website must be refreshed with the blood of owners and designers. It is its natural manure.CUTCODEDOWN.COM