Image Map Image Map
Page 5 of 12 FirstFirst 123456789 ... LastLast
Results 41 to 50 of 116

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

  1. #41
    Join Date
    Mar 2009
    Location
    DE, USA..
    Posts
    2,701

    Default

    This game isn't CPU tied (other than the joystick) right? I should be able to run this on my 486 boxen just fine, I'd imagine..
    Resident Self-Proclaimed 486 and Pentium-class Machine Expert
    More commonly known as "Yushatak"
    www.yushatak.com

  2. #42

    Default

    Quote Originally Posted by Raven View Post
    This game isn't CPU tied (other than the joystick) right? I should be able to run this on my 486 boxen just fine, I'd imagine..
    I reprogram the PIT to increment a user counter that I check against (using a divider to 120 times a second), as such the game should be properly throttled on pretty much anything... take a gander into TIMER.PAS... I like constants with meaningful names on them.

    The game logic updates every six user timer ticks on level one, every five timer ticks on level 2+, and when it goes really fast late game it's every four ticks. I use those ticks to implement time-slicing of the game logic to spread out the longer routines around the things that have to update every tick (sound and keyboard)... Tick 0 draws the sprites, tick 1 reads joystick, tick 3 handles game logic for the next sprite update. Ticks 4+ are left empty and thanks to the overflow method I use for the timer can pick up the slack should the first three run over their alloted time, causing only a minor disruption in the audio (barely noticable)

    Originally I was running the external timer update at 4khz as I was thinking on doing a Covox-type soft-synth, but ditched that as there's no way a 4.77mhz machine can keep up with that and gameplay.

    But bottom line, it's properly speed throttled on everything faster than 4.77mhz.

    I always found it strange the lack of this on many PC games -- back when all there was is the original 4.77mhz PC I can see programmers not thinking "what if there are faster machines" -- but that we still had new games coming out with broken/incomplete speed throttling as late as the 386 being commonplace just blows my mind.

    The PIT isn't THAT complicated! It's funny because you still hear people saying things like "The early PC's lacked accurate timers" -- BULLCOOKIES!
    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

  3. #43
    Join Date
    Mar 2009
    Location
    Pleasant Hill, CA USA
    Posts
    2,267
    Blog Entries
    1

    Default

    Right, its not running right on my 5160. The graphics comes up garbled as if it is trying to run at a resolution my monitor won't handle.

    What resolution does the game try to run in when it detects EGA? I have a 256k EGA Card and an NEC V20 CPU.

    It does run if I use the /SAFE switch.

    also VidTest.exe returns 0x00 No Display, but the game exe says that it detects EGA.

    IBM 5160 - 360k, 1.44Mb Floppies, NEC V20, 8087-3, 45MB MFM Hard Drive, Vega 7 Graphics, IBM 5154 Monitor running MS-DOS 5.00
    IBM PCJr Model 48360 640kb RAM, NEC V20,, jrIDE Side Cart, 360kb Floppy drives running MS-DOS 5.00
    Evergreen Am5x86-133 64Mb Ram, 8gb HDD, SB16 in a modified ATX case running IBM PC-DOS 7.10

  4. #44

    Default

    Try running "paku /debug"? That'll pause the initialization screen so you can see what video card you've got installed.

  5. #45

    Default

    EGA's are a odd mix -- I've tested five different cards and had three testers -- and of a total of nine machines 6 worked proper, and 3 others just flaked out -- whcih is why I put the "safe" switch on it in the first place.

    I'm not sure why some EGA's reject it -- though two of the three cards that didn't like it so far were ATI. I have a small program that dumps the appropriate CRTC data for 'real' mode 2. Lemme see if I can find that again and we can see if your card outputs anything. The Offending cards all reterned a empty BIOS data area for "real" mode 3, meaning that the card itself probably woudln't work with a CGA monitor either. (no 640x200 mode 2, no 80x25 with a CGA plugged in)... either that or they disable that support when a EGA monitor is plugged in, something a real IBM EGA doesn't do.

    The "resolution" it tries to set is "real" mode 2 80x25 text mode, which is 640x200 (as opposed to the mode 2+ 640x350 default) -- the mode the EGA uses when connected to a CGA display. This mode SHOULD function properly on a EGA display since the 640x200 16 color mode works just fine so we know the monitor can handle the timings.

    Oh, and vidtest would return 0x00 on a 5160 as that uses the PS/2 / VGA only BIOS detection routine. Since that's pre PS/2 and pre-VGA, that BIOS call doesn't exist... I created that specifically to test telling the difference between a VGA and MCGA.

    Apart from being squished vertically with the black stripe across the bottom, everything else checks out ok in /safe, right?
    Last edited by deathshadow; February 14th, 2011 at 06:59 PM.
    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

  6. #46
    Join Date
    Mar 2009
    Location
    Pleasant Hill, CA USA
    Posts
    2,267
    Blog Entries
    1

    Default

    Quote Originally Posted by deathshadow View Post
    Apart from being squished vertically with the black stripe across the bottom, everything else checks out ok in /safe, right?
    I would have not noticed the squishing or the black line if you had not pointed it out. So it yes, it runs fine with the /SAFE option.

    IBM 5160 - 360k, 1.44Mb Floppies, NEC V20, 8087-3, 45MB MFM Hard Drive, Vega 7 Graphics, IBM 5154 Monitor running MS-DOS 5.00
    IBM PCJr Model 48360 640kb RAM, NEC V20,, jrIDE Side Cart, 360kb Floppy drives running MS-DOS 5.00
    Evergreen Am5x86-133 64Mb Ram, 8gb HDD, SB16 in a modified ATX case running IBM PC-DOS 7.10

  7. #47
    Join Date
    May 2003
    Location
    Back of Burke (Guday!), Australia
    Posts
    2,866

    Default

    deathshadow wrote:

    System Requirements
    4.77mhz or faster 8088
    128k of RAM (67,584 bytes free in DOS)
    CGA,Tandy/PcJr, EGA or VGA video


    With specs like those I would have been able to run that on my dream CPC machine, sadly the powers that be which only criticise the 8088 processor are missing out!

    I had thought I had the slowdowns with joystick enabled dealt with on 4.77mhz machines, but there can still be occasional lag at certain points in the game. It's not a gameplay breaker, but it's not as smooth as a 7.15mhz or faster machine will deliver. Leaving joystick disabled it runs just fine on the slower clock speed.

    Nothing to do with the way the Input Routine has to receive the return codes from the Joystick. If it's working fine from the cursor key from the keyboard, then it won't be that.

  8. #48

    Default

    Quote Originally Posted by CP/M User View Post
    Nothing to do with the way the Input Routine has to receive the return codes from the Joystick. If it's working fine from the cursor key from the keyboard, then it won't be that.
    Actually it has EVERYTHING to do with how the PC joystick interface works.

    The problem stems from IBM cheaping out on the original game card and not putting a real analog to digital converter in there. Instead all there is for parts is a capacitor and a comparator. To read the position of the analog joystick you output $FF to the joystick port, which discharges the capacitor. The Joystick's pot is wired between the capacitor and power changing how fast the capacitor charges back up -- the comparator fires changing the value at the joystick port when the capacitor is fully charged.

    So to read the joystick you send $FF to discharge, and then run a tight loop with interrupts disabled waiting to see how many times your code loops until the capacitor is charged. The number of times you loop is the joystick position... as such, it takes longer to read 'right' or 'bottom' than it does to read 'left' or 'top'...

    Basically to read the joystick the code is this:
    Code:
    positionX:=0;
    port[$201]:=$FF;
    repeat inc(positionX) until (port[$201] and $01);
    
    positionY:=0;
    port[$201]:=$FF;
    repeat inc(positionY) until (port[$201] and $02);
    So when X is zero, the X loop takes less time to run, when Y is zero, the Y loop takes less time to run.

    My joystick position code uses ASM and decrements CX -- that way I can leverage "loop" so that if no stick is plugged in the system doesn't go off to never never land.

    Code:
    function joystickPosition(stick:byte):word; assembler;
    asm
      mov  ah,1
      mov  cl,stick
      and  cl,$03
      shl  ah,cl
      mov  cx,$3FFF
      mov  dx,stickPort
      mov  al,$FF
      cli
      out  dx,al
    @testLoop:
    	in   al,dx
    	test al,ah
    	jz   @done
    	loop @testLoop
    @done:
    	sti
    	or   cx,$C000
    	not  cx
    	mov  ax,cx
    end;
    Killing the interrupts makes the result have less "jitter".

    It's 'cute' because while it makes the analog joystick interface really cheap to make, it is also inaccurate, inconsistent across systems, the values returned change based just on the speed of the machine you're running it on, can change just because the capacitor warms up during gameplay, etc, etc... There's a reason as soon as USB came along the PC joystick interface went the way of the Dodo.

    The TRS-80 color computer was similarly afflicted, though nowhere near as badly as the PC. On their version of the interface they use the 6 bit DAC to output a reference voltage, which the comparator then returns if that reference voltage is higher or lower than the voltage returned by the stick... so to read the position you have to compare against every voltage the DAC can output. (best done with divide and conquer though many people just looped like on the PC)

    Honestly, the PC version is such a flaky piece of trash, it's a miracle anyone was able to write games that worked with it in the first place.

    Quote Originally Posted by CP/M User View Post
    With specs like those I would have been able to run that on my dream CPC machine, sadly the powers that be which only criticise the 8088 processor are missing out!
    Yeah, even if you could port it those 8 bit registers just wouldn't be fast enough to keep up with the code... I was playing with the 160x200 PCJr/Tandy modes which are similar to the 160x200 of the amstrad -- and that drags the game performance down even further.

    One cute thing about my using such a "low resolution" is it ends up less pixels to shove around per sprite... which is how I was able to get such smooth gameplay on a 8088 in the first place compared to 320x200 4 color games. A 5x5 sprite ends up (with 4 bits 'overscan') 30 bytes to write to memory where the scanlines are at least planar in a 16 color mode. Writing the same code to the CGA ends up needing more logic to handle the 'every other scanline' memory interlace, which ends up taking longer on top of having four times as many pixels to fill AND having to handle shifts across a 32 pixel area width... That's 80 bytes per sprite to send to memory and 640 bytes of RAM per sprite if you pre-store your shifted copies. The other alternative being weighing yourself down with RCR hi16; ROR lo16; LAHF; XOR AL,AL; AND AL,CFMask; SHL AL,CFShift, AND lo16,AX -- for every scanline (ouch).
    Last edited by deathshadow; February 15th, 2011 at 03:21 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

  9. #49

    Default

    It doesn't seem to like my Zenith SupersPORT very much. I have an external CGA monitor attached. I seem to be getting about the top third of the screen. Everything looks very stretched. It cuts off about halfway through "ESC TO EXIT". I tried /debug and it reports a CGA video card. Suggestions?

  10. #50

    Default

    Quote Originally Posted by tomasont View Post
    It doesn't seem to like my Zenith SupersPORT very much. I have an external CGA monitor attached. I seem to be getting about the top third of the screen. Everything looks very stretched. It cuts off about halfway through "ESC TO EXIT". I tried /debug and it reports a CGA video card. Suggestions?
    I just grabbed my Sharp PC-7000 out of it's box in the garage, which 'under the hood' is basically the same hardware -- and sure enough I not only get everything stretched, but on the LCD blink is still enabled (shades of the PCJr).

    Digging deeper the Sharp uses the Chips and Tech 82c425 which is not a true CGA -- It appears thanks to the LCD support they ditched the ability to reprogram the character scanline height to anything less than 8. There is no fix for that, so people with CGA equipped LCD laptops are likely never going to have support for my games.

    Though I'm going to play with the extended CT82c425 and CT82c426 registers to see if maybe one of those will straighten things out. I see a second value declaring vertical sync width and scanline totals in the spec... and there's a bit that enables/disables read/writes to the rest of the timing registers -- $3D4 index $DF -- this lockout is probably done so that you don't send values that could fry the LCD since reprogramming the CRTC to non-BIOS values can be risky.
    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

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •