Image Map Image Map
Page 15 of 21 FirstFirst ... 5111213141516171819 ... LastLast
Results 141 to 150 of 204

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

  1. #141
    Join Date
    Sep 2013
    Location
    Ruston, Louisiana, United States
    Posts
    62

    Default

    nice project ^^

  2. #142
    Join Date
    Sep 2013
    Location
    Ruston, Louisiana, United States
    Posts
    62

    Red face

    I am working on another game project for the XT

    code named project 16

    http://4ch.mooo.com/16/

    here is the official website ^^

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

    Default

    Looking good! If you need help with coding certain aspects, you may want to create a new thread, as this one -- as distracted as it gets -- is dedicated to MagiDuck.
    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. #144

    Default

    Quote Originally Posted by Scali View Post
    Well, technically, the Adlib is 80s tech It came on the market in 1987.

    I was wondering what the best way would be to approach designing sounds. Seeing your tool was very helpful and inspirational!
    Yep, meant to say early 80s there

    Glad to hear the video could be of use to someone so experienced. My poor understanding of programming concepts has usually resulted in me making my own rudimentary tools, instead of painfully reading through pages of specs for things like PCX loading or level editor files. Since I pretty much only started to understand binary files and memory about a year ago I'm hoping I can shake off the worst parts of that habit.

    Your blog post was a fun read, I've already read many of your previous posts and am slowly starting to understand the technicalities. If you're about to make those multiplexed frequencies, you probably need something very close to MONOTONE so I'm surprised to hear you would still opt to make your own editor.

    Actually went through PakuPaku's SOUND.PAS for the first time and tried to see how it stored note sequences... If I understood correctly it stores every note/event as an individual object with links to the first and next note in the pattern. Makes sense I suppose, since every note object can store data needed for every sound device and the sequence(s) are only played when the player can't interact. Just wondering how much overhead this would cause compared to a simple string of data. Although considering long sequences with variable pauses between notes the solution seems to make more and more sense. I'd still be terrified of creating a new object for each note and hoping they'll be deleted from memory reliably eventually.

    My own sound system just uses a 64 note buffer, where notes from the main track are copied when a sound effect is requested. The buffer plays one note per frame and clears it afterwards. A nice side effect is that some previously queued notes can survive even if a new sound effect is queued on top of them. I'm supposing some NES games do things somewhat like this, since sound effects can reserve a channel for themselves for their duration and free it for music afterwards.

    Quote Originally Posted by xjas View Post
    I'm trying to imagine what would have happened if this had been around in say 1982 (or even 85 after SMB1 came around) ... it would have changed EVERYTHING about gaming on computers for years to come.
    Thanks for trying it out
    Certainly a fun thought experiment, although I think the same could (or should be able to) be said for most modern homebrew projects. I'm more and more amazed at what old games could accomplish, considering the tools and information available at the time. Just opening up a text editor in DosBox with settings equaling the 5150 is so sluggish that I don't see how people could survive development back then. Every typo would cost at least three minutes of starting up editors and compilers.

    What I've got is a single laptop with:
    - Notepad++ for editing.
    - Photoshop for graphics
    - TilED for levels
    - A hex editor for debugging files
    - Sourcetree for version control
    - DosBox @ 40000 cycles for compiling and data conversion.
    - DosBox @ 8000 cycles for quick testing
    - DosBox @ 270 cycles for target testing
    - Internet full of information
    - Thousands of old games to learn (steal?) from

    All running at the same time and it's still taken over two years to get at 95% complete of a game

    But hey, progress has been made. Tilesets are pretty much done, there's a bunch of new levels and a new reward for completing levels 100%. Alot of little additions and tweaks in the code and it still mostly runs decently 270 cycles.

    Still wondering about the problem of reloading levels faster after dying... I'll probably go with storing a seperate version of each level with only the tiles that could potentially change.

    Quote Originally Posted by sparky4 View Post
    I am working on another game project for the XT

    code named project 16

    http://4ch.mooo.com/16/
    Looks really intriguing! Not too many japanese style games for old PCs. At least in english... Zone 66 is the only one that comes to mind right now. But yeah, probably a good idea to make your own thread for the project since this one's already going into so many directions

    I'll be sure to follow up on your dev blog at least

  5. #145

    Default

    Quote Originally Posted by mangis View Post
    Actually went through PakuPaku's SOUND.PAS for the first time and tried to see how it stored note sequences... If I understood correctly it stores every note/event as an individual object with links to the first and next note in the pattern.
    It's actually a variation on how midi works, with a unique header.

    fileHeader Offsets:
    0x00 BYTE number of tracks
    0x01 BYTE tempo
    0x02 start tracks

    trackHeader Offsets:
    0x00 BYTE Device channel/voice number
    0x01 BYTE Track Patch/Voice number (does not apply to all devices)
    0x02 WORD Track size in bytes
    0x04 start trackData

    trackData Values:
    For the track data the top 2 bits determine operation, bottom 6 are data:
    0b0000000 == end of data
    0b00xxxxxx == wait x+1 "ticks"
    0b01xxxxxx == note x on -- if x is zero, that's a note off.
    0b10xxxxxx == set volume x
    0b11xxxxxx == change patch (currently disabled as PP doesn't use this)

    1 tick == 1/4th of a beat, so shortest possible note is a 16th. Originally I wanted 48ths for triplet accuracy, but a 4.77mhz machine can't keep up with that. (starting to see why the original MPU401 had a hardware mode!)

    To play the tracks I just point the current track pointer at the first track and loop through them making them "step" until "next" is nil. Each "step" method decrements the "wait" if set, if not set it pulls the next command byte from the pointer into the track.

    Theoretically this format could support up to 255 tracks. 256 if I changed it so number of tracks started at zero.

    The difference from MIDI:

    1) I only support 64 notes, not 128, making my format is single byte commands while MIDI is multi-byte of varying lengths.

    2) MIDI is a single data stream time indexed where the "tracks" are mixed together as they would occur. Mine keeps the tracks separate.

    So... I know what you're thinking; Why did I make my own format? I wanted something tiny for the data stream. As a .MID thanks to each command at minimum taking 6 bytes the data would have been five times larger in memory.

    What it sounds like mangis is doing is the "tracker" method, much akin to how an Amiga mod file works where he has a fixed size table that contains the "track". That can chew up a lot of memory fast and result in processing operations that don't need processing... but said approach has the advantage that like a piano roll it's very easy to make new music for.

    Basically if his approach was an unencoded raw bitmap, mine's RLL encoded.

    Paku 2.0 will use a somewhat more simplified implementation of the same concept as it only supports two tracks (bass and lead) since really the entire game doesn't actually use more than two voices at once. It's also going monolithic so the music will be stored in the data segment as constants, so the tempo set and number of tracks header is going away. I may also flip the control bits to the bottom to make it more efficient and mix in some ASM to shrink the code size, though since nothing else is really going on inside the music playback the effort may be a waste of time for PP... though 2.0 is a testbed for future games where I may have music playing during gameplay, hence it's worth it in the long run to implement this now.

    I've been playing with just using .mid for future projects, or making my own variant of it. The time index per event approach has it's merits in being very simple to perform operations with. I'm thinking to keep it simple having this:

    0x00000000 == end of data
    0x0xxxxxxx == wait x
    0x1xxxyyyy == command x, channel y

    Then the command would be followed by a data byte. This is similar to how MIDI operates, but with smaller/easier time indexes that should take less time to process.
    Last edited by deathshadow; October 10th, 2015 at 07:49 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

  6. Default

    Quote Originally Posted by mangis View Post
    Since adlib and other popular soundcards came much after IBM 5150, it ruins the "roleplaying the 80's" element of the development for me.
    Quote Originally Posted by Scali View Post
    Well, technically, the Adlib is 80s tech It came on the market in 1987.
    Yeah, but the 5150 was discontinued in 1987. I'm guessing the emphasis is on the 5150, not on the full decade.

    Honestly, even the Covox only came out in 1986 five years into the 5150's six-year run. For authentic period-accuracy it's gotta be the PC speaker first and foremost.

    That being said, my own 5150, when I get it and my shit back together, is totally going to see a Covox attached. Admittedly, that's in part just because the setup I'm working towards will end up having two LPTs, and while LPT1 gets the printer, I gotta put LPT2 to good use as well, because otherwise things would be, err, ritually unclean.

    Planned setup, in case anyone cares:

    slot1: original CGA w/ RGBI and composite output
    slot2: AST RAMpage! RAM card w/ 640K; possibly some extra EMS for use as a RAM drive
    slot3: hardware-hacked Hercules clone, so it can drive a VGA CRT I have unless I actually buy a 5151 monitor too; this card includes an LPT(2) <-- Covox
    slot4: NIC; not decided yet; need to know which 16bit NICs work in 8bit slots or if there are 8bit RJ45 NICs advice/recommendations welcome
    slot5: multi-IO controller; has 2 floppy drive controller, RTC, 2 serial ports [ribbons threaded out of case; COM1 for mouse; COM2 hypothetically for modem use, or in practice prolly for null modem cable connectivity; I wonder if the NIC will at all be faster?], 1 game port, and one LPT(1) <-- printer

    PS: Does anyone know what that round hole in the back of the case is for? I know there's a little cover for it, and I have the cover, and besides, I'm actually using that hole to thread the serial port ribbon cables out, but what's the hole really for? Some peripheral that never saw the light of day? Some kind of case lock?
    Optional original IBM cigarette lighter? Or an aperture for endoscope entry for final inspection? Clandestine classroom chewing gum disposal? Inquiring minds want to know.

  7. #147
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    1,674

    Default

    Quote Originally Posted by mangis View Post
    Your blog post was a fun read, I've already read many of your previous posts and am slowly starting to understand the technicalities. If you're about to make those multiplexed frequencies, you probably need something very close to MONOTONE so I'm surprised to hear you would still opt to make your own editor.
    Well, my idea is to play back MOD pattern data. But instead of the samples in a MOD, I would have PC speaker 'instruments'. I only need an editor for these 'instruments'. I guess the requirements for this are slightly different from a full tracker like MONOTONE, so I don't think I can avoid making my own editor for best results.
    Indeed, I could use MONOTONE as a start... I could export a pattern from MONOTONE as an 'instrument' for my system.
    My main concern here is that trackers such as MONOTONE do not allow editing sounds at the tick-level. For MODs this is not an issue, since the samples give you extra precision. But in my case the 'instruments' play this role. The pattern editor already does the rest.

  8. #148
    Join Date
    Dec 2014
    Location
    The Netherlands
    Posts
    1,674

    Default

    Quote Originally Posted by ropersonline View Post
    Yeah, but the 5150 was discontinued in 1987. I'm guessing the emphasis is on the 5150, not on the full decade.
    It's all quite arbitrary I guess.
    Even though the 5150/5160 were no longer produced, software and hardware supporting these machines, and compatible clones, was still produced for years.
    Although... perhaps more interesting would be to support PCjr's built-in audio chip?
    As I understood, the game itself already works on PCjr.

  9. #149
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    4,570
    Blog Entries
    1

    Default

    Quote Originally Posted by ropersonline View Post
    That being said, my own 5150, when I get it and my shit back together, is totally going to see a Covox attached.
    I don't think you'll see a lot of software other than Covox's own utilities that will work on a 5150; it takes a lot of horsepower to drive an LPT DAC.

    The Disney Sound Source was engineered for a 4.77MHz system; it has a 16-byte FIFO and maxes out at 7KHz, reducing the interrupt load for a slow CPU dramatically. Driving a Disney Sound Source (properly, by software that is programmed specifically for it) works on slower systems. Unfortunately, all of the games that drive it properly that I know of (Arachnophobia, Rocketeer, etc.) require 8MHz to be fun. The educational titles probably work fine though.
    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)

  10. Default

    Quote Originally Posted by Trixter View Post
    I don't think you'll see a lot of software other than Covox's own utilities that will work on a 5150; it takes a lot of horsepower to drive an LPT DAC.

    The Disney Sound Source was engineered for a 4.77MHz system; it has a 16-byte FIFO and maxes out at 7KHz, reducing the interrupt load for a slow CPU dramatically. Driving a Disney Sound Source (properly, by software that is programmed specifically for it) works on slower systems. Unfortunately, all of the games that drive it properly that I know of (Arachnophobia, Rocketeer, etc.) require 8MHz to be fun. The educational titles probably work fine though.
    Thank you very much for this information.

    Do you know if it's possible to build or buy the DSS on a budget? (Zero hits on ebay for the DSS. Are designs freely available?)

    Btw., I've also just noticed that this picture on Wikipedia's Covox article shows that the original Covox was a dongle that again provided a parallel port at its back end. Does this mean that the passed-through parallel port was still usable e.g. for a printer? Presumably you couldn't print and play audio at the same time though, right? (I know, most PCs back then didn't multi-task anyway, but for the sake of argument.) I guess if the Covox doesn't "eat up" a parallel port, then my semi-ludicrous reasons for considering the Covox sound upgrade in the first place don't even apply...

    Getting back to scali's comment above, didn't you, Trixter, have a PCjr? I know nothing about it or its audio chip. Have you (has anyone) tried to run Magiduck on it? (Apologies if that's already ITT; I read it before but might have forgotten.)

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
  •