Image Map Image Map
Page 12 of 21 FirstFirst ... 28910111213141516 ... LastLast
Results 111 to 120 of 204

Thread: MagiDuck, a DOS / CGA text mode game project

  1. #111

    Default

    Alpha 2 of the game is now available for download: http://www.indiedb.com/games/magiduc...giduck-alpha-2

    I got a 386 VGA machine from a super-friendly colleague, so here's a video of the game running on real hardware for a change:



    List of changes:
    - Support for MCGA, Tandy and PCJR-graphics. (Most likely won't work.)
    - Special handling for non-wrapping 32k video buffers.
    - Save/Load game system.
    - Improved scoring.
    - New levels.
    - Push buttons, doors, growing pathways.
    - Some enemy behavior tweaks.
    - More reliable spawner system.
    - Cleaned up redundant/stupid use of stack from assembly routines.
    - Keyboard state save (caps, num, scroll) should work now.
    - Shoot / Jump keys changed to Z / X.
    - Cheat keys: (Q = full health, E = complete all levels)

    ---------------------------------------------------------------------------------------------

    PCJR, Tandy and MCGA detection/initialization is based on PakuPaku's source code. I copypasted some code snippets and followed the same logic on others. So more credit owed to DeathShadow, will get to that. Obviously any blame of it not working is on me

    The scroller handles non-wrapping 32k buffers (EGA, VGA, MCGA) in the following manner:
    - Page offsets are placed near the center of the buffer.
    - Once either page offset is nearing 0 or 28000, both pages are copied back to starting positions and the offsets changed there too.

    Tandy and PCJR support assumes that memory wraps like with CGA. Since the machines use RAM for video memory, I can only hope that the address multiplexer manages display wrapping too. Didn't find any confirmation on this from the PCJR manual. All the memory writes of the game are wrapped by code, so they can't leak into unwanted areas.

    Vsync and video memory start offset change for MCGA, PCJR and Tandy follow CGA-logic: they change the offset during vertical retrace. Hopefully the adapters handle it like CGA does, otherwise it will flicker. On MCGA it will also attempt to change the font to 8x8 with INT 1112h.

    After hearing how the game sounds on an actual PC-speaker, I took out the highest octaves from the sound effects. Picking up diamonds was seriously painful with the original sounds.

    Also noticed that my test machine set up a european code page in AUTOEXEC.BAT, so ASCII 222 was something completely different. Wondering if it'll be worth the trouble to add some code to overwrite that character data if EGA or VGA is detected...

    There's so much new stuff here, that I'm preparing for a round of fixes and an Alpha 3 release. So here's hoping work on Beta 1 can start as soon as possible

    TO-DO for Beta 1:
    - Boss behavior code and graphics.
    - 2 tilesets.
    - A couple more levels and better difficulty curve.
    - Secret level logic.
    - In-game manual.
    - In-game readable messages.
    - Ending screens (maybe a few different ones depending on players % of completion).

  2. #112
    Join Date
    Feb 2012
    Location
    Ioannina , Greece
    Posts
    168

    Default

    amazing!!!!

  3. #113
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    4,427
    Blog Entries
    1

    Default

    Quote Originally Posted by mangis View Post
    Tandy and PCJR support assumes that memory wraps like with CGA.
    If you mean "when I write to an address beyond 16KB it shows up in the first 16KB", this is true if you are writing to segment 0xb800. If you mean "when I set the 6845 start address register to show something beyond 14-bits' worth of memory, the display wraps around" then this is also true.

    Vsync and video memory start offset change for MCGA, PCJR and Tandy follow CGA-logic: they change the offset during vertical retrace. Hopefully the adapters handle it like CGA does, otherwise it will flicker.
    This should also work.
    Offering a bounty for:
    - Documentation and original distribution disks for: Panasonic Sr. Partner, Corona PPC-400, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)
    - Any very old/ugly IBM joystick (such as the Franklin JS-123)

  4. #114
    Join Date
    Mar 2006
    Location
    Massachusetts, USA
    Posts
    1,788

    Default

    Hi mangis,

    I tried Alpha 2 on my Tandy 1000 TX and it worked great in the CGA and Tandy and PCjr modes, although it oddly detected a Tandy TL/SL with the tandy parameter. Everything was very smooth with an 8MHz 286. I found the gameplay to be refreshingly challenging. I appreciated the level design, the numerous types of enemies and obstacles. Your sprites are really colorful and have some real personality. I wish you the very best and hope you will get to the point of releasing a "final" version.

    I hope you can add joystick support to the game, although I know the joystick eats up quite a bit of CPU time. Also, when you lose a life, the loading seems like its loading a new level instead of the same level. I hope that can be improved. I wish I could offer more than the occasional word of encouragement and advice and testing on real hardware.

    Considering the current code size is 122KB, perhaps eventually a 5.25"/3.5" DD floppy release would be in order with a box and manual, maybe even a codewheel! Well, maybe not the last one .
    My Retro Computing and Vintage Gaming Blog : http://nerdlypleasures.blogspot.com/

  5. #115
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    4,427
    Blog Entries
    1

    Default

    Quote Originally Posted by Great Hierophant View Post
    the joystick eats up quite a bit of CPU time
    Not always; if all you care about are digital directions in the least amount of time, a coarse routine that measures both the X and Y axis of a single joystick burns up to 20 scanlines as measured on a PCjr (about 10% of your frame time, so whether that is "quite a bit" depends on what you're doing, I guess).
    Offering a bounty for:
    - Documentation and original distribution disks for: Panasonic Sr. Partner, Corona PPC-400, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)
    - Any very old/ugly IBM joystick (such as the Franklin JS-123)

  6. #116

    Default

    Quote Originally Posted by Trixter View Post
    Not always; if all you care about are digital directions in the least amount of time, a coarse routine that measures both the X and Y axis of a single joystick burns up to 20 scanlines as measured on a PCjr (about 10% of your frame time, so whether that is "quite a bit" depends on what you're doing, I guess).
    We've been around this bend a few times, and I'm starting to think you've either got a MASSIVELY tricked out Junior, or there's serious differences on the joysticks and interfaces between yours and mine.

    Using the background color scanline trick, if I wait for vertical refresh to end on an unexpanded junior, I get a range of 2..15 in the output on both axis with one stick active. top-left (2,2) using my "try to read all four axis at once" routine takes maybe 30 scanlines, bottom right taking pretty much 90% of the frame. Running from expanded memory

    That's with a flat unmodified junior, AMD D8088, and the actual IBM Junior sticks. I have a adapter for using standard PC sticks, the WICO I have the resistors are too low and charge the caps too fast to get a reading (this is true on anything less than a AT with that one), an a Kraft that DOUBLES these numbers. (10k pots instead of 5k, so twice the execution time and accuracy).

    Like a LOT of the numbers you quote on things, they're a fraction what I'm seeing here on what should be the same hardware.
    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

  7. #117
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    4,427
    Blog Entries
    1

    Default

    Quote Originally Posted by deathshadow View Post
    Like a LOT of the numbers you quote on things, they're a fraction what I'm seeing here on what should be the same hardware.
    Well, that's a bit harsh.

    The burden of proof is on the claimant, so I guess it's up to me to produce a video backing up my claims. I will produce source code for reading the X and Y axis of a joystick and measuring how long it takes, then a compiled binary, then a video of a real system (or more) running that binary. Until I do, nobody should believe anything I write about joysticks.

    Edit: I just realized I don't have to, because I already did this the last time you accused me of making up numbers. Here's the source, binary, and photos of the results: ftp://ftp.oldskool.org/pub/misc/Soft...ming/joybench/
    Offering a bounty for:
    - Documentation and original distribution disks for: Panasonic Sr. Partner, Corona PPC-400, Zenith Z-160 series
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)
    - Any very old/ugly IBM joystick (such as the Franklin JS-123)

  8. #118

    Default

    Quote Originally Posted by Great Hierophant View Post
    I tried Alpha 2 on my Tandy 1000 TX and it worked great in the CGA and Tandy and PCjr modes, although it oddly detected a Tandy TL/SL with the tandy parameter.
    Great news, thanks a bunch! The video initialization is identical for both Tandy 1000 and TL/SL, that's why the tandy parameter defaults to TL/SL. Using the override skips actual video detection completely.

    Quote Originally Posted by Great Hierophant View Post
    I hope you can add joystick support to the game, although I know the joystick eats up quite a bit of CPU time. Also, when you lose a life, the loading seems like its loading a new level instead of the same level. I hope that can be improved.
    True, the whole level is loaded again when the player dies. Currently the game doesn't have a way to return the original spawner states and changed tiles back to their initial values. It should be quite doable though without much of an increase in memory footprint. Admittedly, the level loading can get quite frustrating if it's a cheap death. I'll look into it.

    I need to read on PC joystick programming before thinking about support for that. The wait times that Trixter and Deathshadow talked seem manageable, since the game spends alot of time idle due to Vsync and a 24fps framerate cap.

    I'm thinking about leaving new tech features for much later though, because the source code is growing quite unreadable. A good clean-up or a rewrite in C would be in order... But I'm not gonna go there until the content for the game is done.

    Quote Originally Posted by Great Hierophant View Post
    Considering the current code size is 122KB, perhaps eventually a 5.25"/3.5" DD floppy release would be in order with a box and manual, maybe even a codewheel!
    Heheh, yeah, I already checked for prices for some printed boxes and 1.44" floppies earlier. Can't deny it would be awesome but also alot of work to fiddle with PDF's for the different prints so that would realistically happen fairly late in 2016 even if I'd have an optimal amount of free time.

    Thanks again for testing and commenting. It means alot to me to hear feedback about this and real hardware tests bring a peace of mind to the development!

  9. #119
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    1,633

    Default

    Quote Originally Posted by Trixter View Post
    Well, that's a bit harsh.

    The burden of proof is on the claimant, so I guess it's up to me to produce a video backing up my claims. I will produce source code for reading the X and Y axis of a joystick and measuring how long it takes, then a compiled binary, then a video of a real system (or more) running that binary. Until I do, nobody should believe anything I write about joysticks.

    Edit: I just realized I don't have to, because I already did this the last time you accused me of making up numbers. Here's the source, binary, and photos of the results: ftp://ftp.oldskool.org/pub/misc/Soft...ming/joybench/
    Wouldn't it be possible to use a timer-interrupt based approach?
    I mean, especially if you are looking for an 'arcade' game which only needs digital left/right/up/down, the polling does not need to be too accurate, right?
    And the worst-case for the joystick is constant-time (at least, on a single machine, you may have to calibrate on a machine-to-machine basis).
    So in theory you'd only need to determine the worst-case interval, and then divide it by 3 in order to get the left-middle-right intervals.
    So you could set up a timer interrupt at the start of a frame, then poll it 3 times, and call it a day.
    Add more intervals as more accuracy is required.

  10. #120

    Default

    Excellent work mangis.

    Appart from the joystick support are you considering to add adlib sound like in paku-paku ???
    PC Speaker is ok but could be great with adlib or even mt-32

    Keep the good work.

    Regards.

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
  •