• Please review our updated Terms and Rules here

It's DONE!!! Paku Paku -- new DOS game!

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

New Joystick Handler
faster, reads both axis at same time

Replaced write/writeln with custom handler
reduced total code size 3%, who knew TP's WRITE was inefficient?

Smaller/simpler graphics 'outtext' routines
removed all the custom number outputs
allows wider use of background erase or transparent

Rewrote 'circling' pixels on menu page
Faster, lower memory use, prevents really slow 8088's from bogging down
(should help jr owners with their slow bottom memory)

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)

Moved music config info into external .DAT files
Lowers heap/stack/code size, makes customization easier

PAT_MT32.DAT, PAT_GM.DAT, PAT_CUST.DAT
Patch files for MT32, General Midi or Custom (see custMidi.txt)

PAT_ADLB.DAT
Instrument Data for Adlib

Distribution built with stack checking off
reduced exe size, faster execution. My stack is fine, don't need the compiler second guessing me.

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.
 
phreakindee said:
Any ideas what might be causing this?
Click to expand...
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.
 
@deathshadow

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.

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



~Kiyote!
 
kiyotewolf said:
@deathshadow
Can you make a tutorial on how you did your own in-browser DOSBOX
Click to expand...
Done!
http://www.deathshadow.com/jDOSBoxHowTo

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.

kiyotewolf said:
, with the lovely Tandy CM-11 monitor around it?
Click to expand...
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.

kiyotewolf said:
How do you even make a *.JAR file anyways?
Click to expand...
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?
 
I actually have a Tandy 1000 HX and a CM 11 color monitor!

Thanks so much for the tips on setting up a jDOSBOX. I appreciate you taking the time to illuminate that for me/us.



~Kiyote!
 
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:

pakupaku1.jpgpakupaku2.jpgpakupaku3.jpgpakupaku4.jpg

PCjr with 384k RAM. Game still works fine though, I did beat the level :)
 
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

http://www.deathshadow.com/downloads/paku_1_6.rar
 
Last edited:
deathshadow said:
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.
Click to expand...
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.
 
@basman74

I hate to interject in the thread for something a bit off topic, but I didn't know how I'd get a hold of you otherwise.

Hey on the Flea system, can you try out this Max Headroom toy program and do a video?

Doesn't your Flea86 have a 4.77Mhz speed? Cause it needs a very slow speed to play the speech through the internal speaker properly.

Please and thank you, would you see if it works, and if it speaks, I would love to see a video of it.

Pretty please!



~Kiyote!

I'm thinking about using your Flea86 if you release it for sale, and the old SPEECH.COM program to make a miniature wearable computer that speaks to me.

Back on subject, I'm tinkering with TP again thanks to the PakuPaku game.

Going to play around with VESA SVGA and TurboPascal.

http://jafile.com/uploads/kiyotewolf/maxhead.zip

http://jafile.com/uploads/kiyotewolf/maxhead.zip

Also in there is the Radio Shack Tandy 16 color Xmas cartoon. I wonder if THAT works on the Flea86. I put that in there for you as something for Xmas. Flea'mas.
 
Last edited:
someperson said:
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).
Click to expand...
ok, something's screwy with the /gm switch as it's looking for the wrong filename. For now, try paku /midi -- which uses pat_cust.dat instead.

Ok, that's really weird:
patchKit.init('PAT_GM.DAT');

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:
oooooh! I downloaded it off of the first post, that's why. I'm used to the first post being updated with the latest version, my bad. :D

I will take a look tomorrow with the latest version!
 
@deathshadow

Step One -- make a floppy image or virtual disk
In order to run any game you need a disk image for the emulator to use. jDOSBox supports the same IMA format (which is just a raw dump) of a floppy, as well as hard disk images. For simplicity sake we'll just be using virtual floppies here. If you want to know more about making disk images and how they are used in DOSBox, check the IMGMOUNT documentation from the official DOSBox website.
Click to expand...

When you create an image of a hard drive, from existing files, and you load it into DOSBOX, not the jDOSBOX, just regular DOSBOX, can you copy files from a physical drive and save it into the *.IMA file, using DOS commands, and then the file, when DOSBOX closes, will save your changes and update the file?

Or is it like, a READ ONLY sorta thing, you can't change it once it's created the first time, like a WORM drive.

Also..

Can you simply extract the files from an *.IMA to a physical drive, using DOS commands, in DOSBOX, just as if the drive image was a regular physical drive, dropping virtual/cloned/image-of into realphysical-media?



~Kiyote!

Was going to start a whole new thread about it, but you had posted part of the details in this thread already.
 
kiyotewolf said:
When you create an image of a hard drive, from existing files, and you load it into DOSBOX, not the jDOSBOX, just regular DOSBOX, can you copy files from a physical drive and save it into the *.IMA file, using DOS commands, and then the file, when DOSBOX closes, will save your changes and update the file?

Or is it like, a READ ONLY sorta thing, you can't change it once it's created the first time, like a WORM drive.
Click to expand...
JDOSBox they're read only (at least when accessed online) because the file doesn't 'really' exist locally. With the regular DOSBox they're read/write, so yes you can go ahead and save to them and it sticks.

kiyotewolf said:
Can you simply extract the files from an *.IMA to a physical drive, using DOS commands, in DOSBOX, just as if the drive image was a regular physical drive, dropping virtual/cloned/image-of into realphysical-media?
Click to expand...
No reason why not. So far as DOSBox is concerned they're all just drives. If you mount a local directory using MOUNT, and a img file with IMGMOUNT, you can copy back and forth no problem.
 
deathshadow said:
So far as DOSBox is concerned they're all just drives. If you mount a local directory using MOUNT, and a img file with IMGMOUNT, you can copy back and forth no problem.
Click to expand...

It should be noted that the image has to have a valid filesystem, which must be specified in the IMGMOUNT command.

A problem with early 160KB and 320KB floppy disks is that they don't allways have the FAT "signature" in the boot sector, thus DOSBOX won't mount them as FAT (and even if they did, the file index table is located in different sectors than the later formats, something DOSBOX can't cope with either).
 
per said:
A problem with early 160KB and 320KB floppy disks is that they don't allways have the FAT "signature" in the boot sector, thus DOSBOX won't mount them as FAT (and even if they did, the file index table is located in different sectors than the later formats, something DOSBOX can't cope with either).
Click to expand...
That's quite odd -- I've not once encountered that... I believe that was fixed as of 0.72, and since we're on 0.74 now...
 
awesome game! testing now on dosbox! :) - congratulations, and i expect seeing more games as good as this! :)
 
You must log in or register to reply here.
Back
Top