K1n9_Duk3 wrote:

Scali wrote:

EGA however runs at 60 Hz. So it will always be desynced.

Oh. Didn't know that. I was just guessing since the DOSBox video catpure usually records 320x200x16 at 70 (point something) fps.

If you set machine=ega, it shouldn't (otherwise there's a bug). CGA and EGA use 60 Hz (and MDA/Hercules is 50 Hz).
However, if you have it to one of the (s)vga setting, then indeed the EGA modes are 70 Hz. This is correct, because that also happens on a real VGA card.
PCs aren't actually as backwards compatible as people tend to think 😀

I've been thinking about this and I wonder, is a higher frequency necessary for OPL tunes because certain instruments need to be updated faster in order to sound correct?

I know DOSBox uses 1000 Hz for DRO files, which I guess is pretty much guaranteed to make it sound exactly as it originally came out the speakers. What would be the consequences of using 1000 Hz for playback on a 286? I know certain songs made by Adlib Tracker II (which really stretches OPL3 to the max) have trouble playing correctly even when recorded as DRO and played back. Certain players play the resulting DRO files perfectly, while others (such as my IMF/DRO player which works perfectly on IMF files and OPL2 DRO files) do strange things on certain songs and parts of songs.

And back to graphics: I think we're definitely using VGA, 256 colors, 320x200 resolution (i.e. standard Mode 13h). Unless someone wants to go through the trouble of using Mode X, that is. The graphics should be stored uncompressed for now, converted from standard 256 color BMP files (the tiles in sheets, the sprites individually). The tiles can be organized into background, midground, and foreground, with most of the stuff in back and mid, and foreground used mostly for sprite placement and special stuff like portals and doors [note: I'm totally flexible on this approach so if someone thinks there's a better way, I need to know so we do it right the first time 😀] The level designer in me says you should be able to place any tile in the background or the midground, but my gut says that may not be practical given memory limitations [programmers, what's the best way to do this?].

Programming: OpenWatcom [what version is best?], real mode. The code should run on either an 8088 or 286, but I think we should target 286 or turbo XT systems with at least some EMS memory. I assume we're using DOSBox for development (or real hardware of course). We should probably limit DOSBox cycles to whatever our minimum target system is (for 286 I think that should be 1500-2000 iirc), just to make sure it works right.

Let's figure out how we store the graphics and how memory management will work, so we can start working on the foundation of the code. Should there be a github page for this? I can start one if it would be useful.

We'll also need preliminary utilities to concatenate the graphics and levels into the game files.

keenmaster486 wrote:

I know DOSBox uses 1000 Hz for DRO files, which I guess is pretty much guaranteed to make it sound exactly as it originally came out the speakers. What would be the consequences of using 1000 Hz for playback on a 286? I know certain songs made by Adlib Tracker II (which really stretches OPL3 to the max) have trouble playing correctly even when recorded as DRO and played back. Certain players play the resulting DRO files perfectly, while others (such as my IMF/DRO player which works perfectly on IMF files and OPL2 DRO files) do strange things on certain songs and parts of songs.

The problem with DRO, MIDI and IMF is that they have no synchronization anywhere. They're just 'captures' of note data.
And when you do that, you need quite a high resolution to avoid notes from accidentally getting quantized too much, and messing up the detail.

However, with tracker-based music, the format itself limits you to only write note updates at a given interval (which is usually the same as the frame rate).
This means that by definition you know when you need to update notes. So the music data comes in with 'batches' of note updates at every frame, and nothing in between. This means you don't need very high resolution.

Here's an example of an AdLib song that was composed that way, in EdLib tracker: https://youtu.be/4ClrU-ne2Us
Does filter effects and everything just fine at just 70 Hz (yea, the video was re-synced to 60 Hz for YouTube).

keenmaster486 wrote:

Unless someone wants to go through the trouble of using Mode X, that is.

Mode X gives you a lot of advantages in animation, because you can use the full 256K of memory on a VGA card. Mode 13h forces you to double-buffer in main memory, and copy to the screen to get smooth animation. This immediately places a big bottleneck on the bus, and basically means you need a fast 386 at least (perhaps even a local bus system), to even get a smooth 25 fps, let alone 70.
So depending on the game and the target hardware, Mode X might actually be a requirement.

I mean, if you take Keen... It deliberately uses EGA mode even on VGA. Firstly, because it only requires half the pixel data of mode 13h for a frame. Secondly, because it gives you the same advantages as Mode X, in that you can use the full 256KB.
Doing a 'Keen' game in Mode X would already require about twice as fast a system as Keen. Doing a 'Keen' in mode 13h would require a much faster system still.

Oh, interesting... thanks, that really clears things up about Mode 13/Mode X. I didn't know that... well, maybe Mode X is a good idea. But it is harder to implement, right? I just have no experience with it, having always used Mode 13 for everything I've ever done in DOS 🤣

For music, maybe we should have a system that directly plays some music tracker format such as A2M.

keenmaster486 wrote:

For music, maybe we should have a system that directly plays some music tracker format such as A2M.

Well, EdLib worked fine for me 😀
It was written by JCH of the Vibrants, and can be downloaded here: http://www.pouet.net/prod.php?which=13357

The player is written in 8086 assembly, and the code is included. So it's compatible and efficient, and can be adapted to your needs if required.

small question: i have done a modex scroller in the past myself, it was rather slow ona 386 sx 25.. also i did not have any hardware helping with all the needed copy/paste of the animated elements(would that require SVGA?);
there were old 286, i think, racing games, which updated a rather big part of the screen while the player was racing and somehow managed on such old weak machines? maybe thats how this problem can be solved performance wise?

keenmaster486 wrote:

But it is harder to implement, right? I just have no experience with it, having always used Mode 13 for everything I've ever done in DOS 🤣

Drawing a pixel in Mode 0x13:

1char *vgaptr = MK_FP(0xA000, 0);
2vgaptr[x + y*320] = pixel;

Drawing a pixel in Mode X:

1char *vgaptr = MK_FP(0xA000, 0);
2outpw(0x3C4, (0x100 << (x & 3))|2);
3vgaptr[(x>>2) + y*80] = pixel;

Not a big deal. Compared to using main memory for double buffering, that is.

Edit: fixed mode X code

mrau wrote:

small question: i have done a modex scroller in the past myself, it was rather slow ona 386 sx 25.. also i did not have any hardware helping with all the needed copy/paste of the animated elements(would that require SVGA?);
there were old 286, i think, racing games, which updated a rather big part of the screen while the player was racing and somehow managed on such old weak machines? maybe thats how this problem can be solved performance wise?

Well, there's two tricks... One is using the latches to blit 4 pixels at a time. The other is using 16-colour EGA mode, with a VGA palette.
That's also what I used in my 1991 Donut demo.

Those older racing games may have large areas of single color. Those areas can be written quite fast, 8 same-coloured pixels in a single byte write in 16-color mode. There are few different write modes in EGA/VGA cards and one would choose the write mode based on what would be the fastest way to write your data.

Also, the Vibrants music driver is very simple to load and use, I once wrote a program for myself to play .D00 music files into OPL register dumps. Even if it is doable, someone must consider what licensing terms the Vibrants driver has, and how does it go along with the licence this game project will choose.

Jepael wrote:

Also, the Vibrants music driver is very simple to load and use, I once wrote a program for myself to play .D00 music files into OPL register dumps. Even if it is doable, someone must consider what licensing terms the Vibrants driver has, and how does it go along with the licence this game project will choose.

This is what it says:

1|       THE BORING STUFF                                                       |
2|       ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯                                                       |
3|       All files in the archive should be distributed in their original       |
4|       form - it is forbidden to modify anything. The player may not be       |
5|       used commercially in any way without permission from the author.       |
6|                                                                              |
7|       The names Vibrants, the SirFace System and EdLib  are trademarks       |
8|       of Jens-Christian Huus. Other product and  company names are the       |
9|       trademarks of their respective owners.                                 |

I guess that's good enough for our needs. We don't need to distribute or modify the EdLib code, and we don't use it in a commercial project.

OK, that sounds good, as long as the license terms are workable... are we sure we won't need to modify the code in any way?
KingDuke: Thanks for the Mode X info. And welcome to the forums! Glad to have you here 😀 I do notice the Mode X code uses more math, though; could that affect the speed in a significant way? Otherwise I think Mode X is starting to sound pretty good. More resolution and square pixels is nice too.
@Scali: I really like the donut demo, and the music. I admit I got sucked into your YouTube channel. Wish I could play the guitar like that 😀

keenmaster486 wrote:

I do notice the Mode X code uses more math, though; could that affect the speed in a significant way?

That depends. I chose the most straightforward way to do things here. You could use a lookup table for the plane mask and you can also split the outpw into two outp commands so you don't have to bitwise-or the number two every time. You generally need to do the same number of byte read/write operations in both modes, with the added port outputs in mode X, which make this mode slightly slower when drawing stuff. But the fact that you get 4 screen pages for easy double buffering more than makes up for that speed-wise. You rarely draw single pixels in a game (except maybe for particle effects). And sprite/tile drawing can be optimized to be actually faster in mode X than in mode 0x13.

In Hocus Pocus, for example, everything moves in multiples of 4 pixels. All sprites and tiles are in VGA memory. That lets the game draw up to 4 pixels at a time by reading/writing one single byte.

keenmaster486 wrote:

I do notice the Mode X code uses more math, though; could that affect the speed in a significant way? Otherwise I think Mode X is starting to sound pretty good. More resolution and square pixels is nice too.

Well, if you just want to plot pixels separately, Mode X will be very slow and cumbersome (then again, doing separate setPixel(x,y) is generally a very slow way to draw anyway. You'll want to group up as many pixels as you can, to take advantage of the full bus width, and to reduce the overhead of calculating pixel addresses). Mode X really comes into its own when you can avoid switching planes.
For example, Wolfenstein 3D uses Mode X, and it renders vertically. It can render the vertical columns in any order, so they can group it per plane. This means it only needs to switch between planes 4 times per frame.

Likewise, in my donut demo I use the 16-colour EGA mode, which also requires switching of planes and setting of masks to draw. However, since I draw flat polygons, I only need to take care of the special cases at the edges. For all the pixels in the center of the polygon, I can just write to all planes at once. Which makes it much faster than mode 13h.
If I wanted to do something like texture mapping however, where every pixel can have a different colour, it would be a lot slower, because I'd have to reprogram the EGA registers for every pixel I want to plot.

keenmaster486 wrote:

@Scali: I really like the donut demo, and the music. I admit I got sucked into your YouTube channel. Wish I could play the guitar like that 😀

Thanks 😀

OK guys, let's get this project off the ground.

Programmers, can one of you start working on the basic framework of the code? I want to get something we can work with, even if just blits images to the screen for now. Pretty sure we decided to use Mode X. If you need test sprites and tiles let me know, I have some you can use. But let's just focus on getting it to run and display something on the screen for starters.

Here's what I think it's going to look like:

-Mode X - 320x240, 256 colors
-OPL2 music (for now) using the Edlib system
-Worry about sound effects later but probably digital samples
-Target minimum system: fast 286/slow 386 with SB2.0+

keenmaster486 wrote:

Programmers, can one of you start working on the basic framework of the code?

🤣

You sound like my project managers - "Progammers, go do stuff"

Badmojo, it isn't hard to write a bare-bones piece of code that loads an image on the screen!! That's all I'm looking for right now 😠 Jepael or someone already did that, in fact. Stop being so negative. I would do it myself but I don't know where to start! Honestly though maybe I should be the one to begin the coding.

leileilol wrote:

everyone has ideas, what matters is execution. but i got a feeling this thread will be stuck in the ideas/concept phase anyhow

leileilol wrote:

leileilol wrote:

everyone has ideas, what matters is execution. but i got a feeling this thread will be stuck in the ideas/concept phase anyhow

This is what I'm trying to prevent from happening.

keenmaster486 wrote:

Badmojo, it isn't hard to write a bare-bones piece of code that loads an image on the screen!! That's all I'm looking for right now 😠 Jepael or someone already did that, in fact. Stop being so negative.

Oh yeah, had forgotten about that because of few reasons.

First of all, what I wrote was not even comparable to a half-decent tutorial how to plot a pixel in 256-color mode. It's no rocket science to go into graphics mode, read a file into video memory and set palette from file. Knowing how to do that is one thing and pretty easy like you said, but knowing how to do that with the tools you got (the programming language C/Pascal/Asm or even compiler (Turbo C/DJGPP or TASM/NASM) you are currently working in is another matter.

keenmaster486 wrote:

I would do it myself but I don't know where to start! Honestly though maybe I should be the one to begin the coding.

Actually, I had this as well. I was so eager to start writing something I did not think first. I picked the tools that are simply not pleasant to work with. I used Turbo C (the freely downloadable version from Borland Museum), and I just began the coding, running the Turbo C in DosBox. But I did not think first if that was the right C compiler, or even if C language was right for this. I had to learn how to call BIOS interrupts in Turbo C, while these would have been better as inline assembly routines (can't do that unless compiling from command prompt). I ended up with just some functions that are not well structured or anything; it's just spaghetti code that does the job 😀
Oh and having Turbo C manage a project with multiple C source files, I still don't know if there's a button to rebuild all the C files and link the executable. I constantly ran into trouble when editing something in some other C file which was not the main project file or something like that.
So now if I wanted to change even to another C compiler, the code would need some kind of rewrite.
I really should try modern Free Pascal compiler to cross compile non-386 DOS executables in Linux.

Oh, and as I did not have anything planned and was just writing code with the flow, there's also no documentation 🙁

I can post here what I have if you want, but it is not much.

I don't think I'm being negative, just realistic. I've attempted to write a few games in my time and to say any of them is close to half finished would be very generous. It's not the coding effort that stopped me - I've been a professional dev for 15 years. Writing a half decent game from scratch - particularly with old tech that google can't help you with - is just a LOT of work.

Pros of working alone is control over everything, cons are obviously that you need to master and find time to do everything - engine code, sprites, user interface / contols, sound, level design, optimisation, etc.

Pros of working in a team is being able to share the load with - hopefully - people who know their sh*t. Cons are that getting > 1 person to pull in the same direction is a full time job in itself, particularly if it's a best effort hobbiest project involving people you met on the internet.