@Jepael @Scali I agree that we should use open-source tools. I also like the idea of using real mode and XMS/EMS (whichever is better in real mode) for memory needed above the 1MB limit. Thanks for the info on various CPUs/modes, that clears things up a bit.

I don't know about having support for both EGA and VGA (i.e. through graphics drivers), the reason being I worry about graphics conversion. Would we draw VGA graphics and, for the EGA version, basically just convert them from 256 to 16 colors? It seems like it would be better to create a redrawn set for EGA or vice versa.

Jepael wrote:

That would work for starters, and in real mode the easiest limit is to fit a tileset into 64kilobytes, which means 256 tiles of 16x16 size at 8-bit palette. You can of course have many tilesets, like per-level tileset or foreground/background tileset.

What if we're using more than 256 background tiles (for instance) in a single level? Could more than one tileset be loaded at a time?

Jepael wrote:

What about music? Sound effects? Back in the day Adlib/EGA or SoundBlaster/VGA would have been the de facto set.

I've given that a lot of thought. Here's what I think:

Music: OPL3. The engine can load DRO files, or some updated version of IMF that supports OPL3 (which would basically be DRO v0.1). This would save memory and CPU time (versus using MOD music) and it would sound awesome 😀 I really like what's being done with various FM trackers (e.g. Adlib Tracker II). Some of the instruments in those songs really sound like actual samples. Support for OPL2 can be added as well, albeit with some instrument dropping. We could use MIDI files and thereby have support for a multitude of cards, but I think targeting just one chip (the chip that every single DOS computer has, pretty much) will allow us to optimize things and make the music sound way cooler.

Sound effects: Sound Blaster. That's really the only way to go here. I think we should have support for every model from SB1.0+, and any bits/samplerate so the user can configure things to their liking and computer speed 😀

Leilei: I really like your talent, keep up the good work! Keep in mind, however, that "hitting spots on the female armor bingo cards" as you said earlier, doesn't really work for this particular game since I want it to be highly suitable for children. I'm sure that was your plan (since you said those are practice etc.), but I just wanted to confirm.

And for resolution: I was thinking 320x200/256 colors, i.e. the standard VGA mode 13. Leilei drew this art with 640x400 or 640x200 in mind; does anyone else think we should use something other than mode 13 (e.g. Mode X maybe)?

Scali wrote:

So I can recommend OpenWatcom for real mode/8086/8088 stuff.

OK, that sounds good to me - would you also recommend that for real mode 286? I would assume things there are pretty much identical.

@Beegle: Yes, I agree with all of this. We would need smaller sprites anyway, I guess art like what Leilei's doing there would work for story art though, right? I definitely think backgrounds would benefit from Leilei's vibrant art style.

Also, somehow you double posted, as Jade seems to have noted 🤣

I'm getting excited about our prospects here. Let's keep it going 😁

Just a little point about music : I would suggest SB1.0 compatibility (OPL2/AdLib) instead of OPL3 because many clone cards don't sound as well for SB16 support as they did for SB1.0. In my knowledge SB1.0 compatibility is omnipresent, while OPL3 is less prevalent.
Added bonus : I have a spare AdLib that I could provide to the Music/Sound team so they can compose on real hardware.

And a small point on graphics : I don't know how we should go for this as I'm not a graphical expert. But my suggestion would be to choose one mode (EGA or VGA) and stick to it. On-the-spot conversion from VGA->EGA would possibly slow down the game (using precious limited resources for our retro platform), while having two versions of each graphic/sprite/image would double the work load of the art team which is not really adviseable either.

I agree that OPL2 support is a must, but I'd really like to have enhanced music for OPL3. Perhaps the songs are composed for OPL3, and then OPL2 versions made by using 9 of the most necessary instruments or something?

As for graphics, I agree with your assessment. I would choose VGA, but we need a consensus. What's everyone else think?

keenmaster486 wrote:

I agree that OPL2 support is a must, but I'd really like to have enhanced music for OPL3. Perhaps the songs are composed for OPL3, and then OPL2 versions made by using 9 of the most necessary instruments or something?

As for graphics, I agree with your assessment. I would choose VGA, but we need a consensus. What's everyone else think?

Well, my preference would be VGA card, regardless of 16 or 256 color mode. In 16 color mode the difference between EGA and VGA is not huge but still. Also my preference would be 256 color mode instead of 16 color mode because it's easier to work with.

Sure, by sacrificing color you'd get larger resolutions like 640x480 at 16 colors, but only about 1.7 video pages. In 256 color modes you only get 320 (or 360) pixels of width (with standard refresh rates), but it can easily be tweaked to 240, 400 or 480 lines. The beauty of tweaked 320x200 mode is that you get almost 4.1 video pages, so even at 320x400 you have double buffering. If that sort of thing is necessary.

keenmaster486 wrote:

OK, that sounds good to me - would you also recommend that for real mode 286? I would assume things there are pretty much identical.

I've never used it for 286 code, but I assume it will be fine. Difference with 8086 isn't that big.

Beegle wrote:

Just a little point about music : I would suggest SB1.0 compatibility (OPL2/AdLib) instead of OPL3 because many clone cards don't sound as well for SB16 support as they did for SB1.0. In my knowledge SB1.0 compatibility is omnipresent, while OPL3 is less prevalent.

OPL3 was introduced with Sound Blaster Pro 2.0, and most clones are SBPro 2.0-compatible.
But historically not many games targeted OPL3. OPL2 sounds good enough, and is supported on a wider range of hardware, so I don't see why not.

Scali wrote:

keenmaster486 wrote:

OK, that sounds good to me - would you also recommend that for real mode 286? I would assume things there are pretty much identical.

I've never used it for 286 code, but I assume it will be fine. Difference with 8086 isn't that big.

Could you give a short crash course how to get started with OpenWatcom? I downloaded it and can't determine which folder has which stuff. It came with several folders of host OS binaries. Either how to develop DOS code in DOS, or DOS code in Linux?

P.S. I have tried Borland Turbo C earlier, I already have some working VGA code for it. Like displaying 256-color 320x200 RAW images with 8-bit palette (exported from Gimp).

Scali wrote:

Beegle wrote:

Just a little point about music : I would suggest SB1.0 compatibility (OPL2/AdLib) instead of OPL3 because many clone cards don't sound as well for SB16 support as they did for SB1.0. In my knowledge SB1.0 compatibility is omnipresent, while OPL3 is less prevalent.

OPL3 was introduced with Sound Blaster Pro 2.0, and most clones are SBPro 2.0-compatible.
But historically not many games targeted OPL3. OPL2 sounds good enough, and is supported on a wider range of hardware, so I don't see why not.

For starters I'd go for OPL2 music. Simply because it is anyway required. Also dual OPL2 and OPL3 cards are fully compatible with OPL2.

The biggest step for using other than OPL2 would be to think how to make use of extra features of dual OPL2 or OPL3 cards. If the underlying song (think of maybe MIDI or tracker music file) is the same, you only need different playing code for enabling panning or echo on dual OPL2/OPL3 cards. OPL3 would need different instruments if 4 operator mode channels are used, and there's only up to six 4-op channels which leaves only six regular 2-op channels if percussive mode is not used.

Another option is to just compose also OPL3 and dual OPL2 versions of the tune, and use the same player/driver to feed data to sound chip.

Granted, the OPL2 driver could still detect OPL3, and use smaller waits between register writes if it can. Remember, the more complexity (on the fly instrument parameter modifying) the music has, the more data needs to be written to OPL chip, and the more time is wasted waiting for the delays to be long enough.

Let's see if there is some OPL tracker format that would be suitable for on-the-fly playing. If there isn't there is always the option to export the music and play back register dump files like .DRO, .IMF, .VGM or the like, but for some reason I really like RDOS RAW format.

Scali wrote:

But historically not many games targeted OPL3. OPL2 sounds good enough, and is supported on a wider range of hardware, so I don't see why not.

Jepael wrote:

For starters I'd go for OPL2 music. Simply because it is anyway required. Also dual OPL2 and OPL3 cards are fully compatible with OPL2.

Well, I guess we have a consensus - we'll at least start with OPL2. Like Jepael said, it would be relatively easy to implement OPL3 support after the fact.

I've worked with both the DRO (for OPL3 music) and IMF (OPL2) formats in my QB game engine, and the implementation was almost identical for both of them. It was trivial to modify the IMF player to accept DRO files, which could then be either OPL2-type or OPL3-type songs, and they would still work. Maybe we could eventually do something like this.

I think we should stay away from "on the fly instrument parameter modifying" as Jepael put it; it seems like that would use up way too much CPU power for our purposes. I like the idea of having separate OPL3 and OPL2 versions of the same songs. On the other hand, this would present problems because in order to take full advantage of the OPL3 chip, you'd have to compose your music with 4-operator channels, square/sawtooth waves, stereo effects, etc. which couldn't easily be matched by the OPL2. We could compose the music for OPL2 and add features for the OPL3 versions.

About graphics, I agree with using 320x200x256 mode, or some tweaked version of it (maybe to get a status bar on the bottom of the screen or something). Double buffering is definitely necessary.

Another thing: What about a level editor? We'll have to develop one and think about what format we're going to use. Should it just be raw data bytes similar to the Abiathar simple-single-level format?

How about tile planes? I would have a background, midground, and foreground, in all of which any tiles from your entire tileset can be placed, just for maximum flexibility, but of course this uses more memory.

Jepael wrote:

P.S. I have tried Borland Turbo C earlier, I already have some working VGA code for it. Like displaying 256-color 320x200 RAW images with 8-bit palette (exported from Gimp).

Awesome! How much different would it be rewriting that for OpenWatcom?

Also, what sort of an IDE (if any) would be used with OpenWatcom?

This is what we're up against.
https://www.kickstarter.com/projects/10930019 … ra-apogee-platf

[rant]
This sort of thing annoys me greatly. Everything about this game - the kid's "too cool for school" name, the insipid smirk pasted on his face, the foul-mouthed and highly annoying console, the highly smoothed graphics, all point to the fact that the spirit of this game is distinctly different from that of early 90's platformers, whatever they may say. Those games were designed by and for intelligent people, and became as much works of art as they were simply great fun. This thing? Well, it seems well suited to your average ill-shaven walking beer can living in his parents' basement who only cares about the latest and greatest way he can be crudely made to laugh.
[/rant]

Don't necessarily listen to me (I get kind of hot-headed and I may be wrong about this), but my vision for our project was kind of to really bring back 90's platformers, instead of crudely mimicing them by removing one dimension from a 3D engine and making up a Macguffin to justify the idea that this child has to blow people to bloody bits with his "badass guns".

keenmaster486 wrote:

Another thing: What about a level editor? We'll have to develop one and think about what format we're going to use.

A. I can say is that a separate level editor will be a must. LDs/mappers should not have to tinker in the code to build their levels; having a separate editor will provide for quick iteration of maps, and stronger/cleaner engine code (if a LD requires new features, tiles, triggers etc., they just ask one of the programmers to implement the new thing for them. Once created, the new feature is accessible in the level editor, and works in-game when playing the map.)

B. Level data should be saved in separate files (i.e. not in the executable) so that we can swap them around easily.

C. This said, if we go with a tile-based approach, we can always have a very simple editor that displays the tiles as letters. For example :

1     A
2    AAA
3   AAAAA       L
4  AAAAAAA     LLL
5  X     X     LLL
6  X  O  X      I
7  X  O  X      I
8--------------------

could represent a house with a tree on the side. As long as the sprites (8x8, 16x16, etc.) can be seen somewhere with the corresponding letter, we should be good. This approach will allow us to work with temporary graphics, and update them as needed later on without having to edit the level itself.

D. Also, I suggest that we have a separate layer for the visuals, and the collisions, and a way to toggle between them in the editor. Having visuals separate from the collision minimizes the possibility of collision/walkthrough errors (ex.: an artist deleting a tile by accident, making a chasm wider, and making the level uncompleteable) when polishing the game graphics. This way at some point we may "lock down" the collisions and concentrate on the visuals without worrying about breaking the level.

E. Doing work for level design will require to have documentation on what are the expected "metrics" for our character, and their abilities. We may take for granted most of these things or think that they will find themselves, but for efficient LD work, clear metrics will be needed in the long run. For examples, purely fictional :
...the character is 2 blocks high.
...if the character crouches, they become 1 block high.
...jumping upward is 3 blocks. (they will bump their head if the roof is under 5 blocks)
...jumping forward is 8 blocks. ( so having a pit of 7 blocks is the wides possible)
...when they shoot their laser, the laser moves forward at 4 blocks/second.
...what happens if a door "closes" and the character is on the same tile? Does he die? Get pushed? If pushed, on which side of the door?
...etc.

keenmaster486 wrote:

This is what we're up against. https://www.kickstarter.com/projects/10930019 … ra-apogee-platf [...] Don't necessarily listen to […]
Show full quote

This is what we're up against.
https://www.kickstarter.com/projects/10930019 … ra-apogee-platf
[...]
Don't necessarily listen to me (I get kind of hot-headed and I may be wrong about this), but my vision for our project was kind of to really bring back 90's platformers, instead of crudely mimicing them by removing one dimension from a 3D engine and making up a Macguffin to justify the idea that this child has to blow people to bloody bits with his "badass guns".

We aren't up against them. They are trying to emulate, fake, recreate a feeling of the 90s. For our project, it will come a lot more naturally given the platform and technology, while they will have to "force" it. Don't worry about it. Platformers were prevalent in the 90s, but the 90s is much more than that. There are many modern platformers that don't taste 90s at all.

You'd need to get this thing beyond the "kicking ideas around on a forum" stage before you can start ranting about the competish - you're not "up against" anything. And newsflash - it's 2016. If intelligent people want to play a 90's game, then they'll fire up Dosbox and play an actual 90's game, but I doubt that 99.9% of the population are sitting around wishing they had a new 90's game to play.

Doing a project like this for fun makes perfect sense to me, but if you're trying to prove a point then it's time to reassess I think.

I'm not all that optimistic for Rad Rodgers. It's repeating Tommy Tronic history to me (Interplay's supposed "comeback" "oldschool platformer" game with a similar premise), and its "mature humor" is going to fall flat and end up limiting its demographic to be succsesful anyway.

I also wonder what Nintendo's legal department thinks about their trailer and the presence of much Nintendo IP throughout (the decals, the NES-derived sidekick, etC)

keenmaster486 wrote:

up against

Are you for real?

Also,

keenmaster486 wrote:

https://www.kickstarter.com/projects/10930019 … ra-apogee-platf

Who cares what they're "going for", the thing actually looks like a bit of fun. I wouldn't back it, but I'd buy the finished product for $5 in a Steam sale.

Guys, I'm sorry - in retrospect I think my post was uncalled for. I think I offended people and I'd like to be the first to say that I was an idiot.

I actually don't think we're "up against" them; it was stupid of me to say that. I guess what I thought was, "Here's the closest thing to '90's platformer' fare that's out there right now; now let's make something more authentic."

I wouldn't buy that game either as a 90's platformer style game or as something else; I just don't like it overall. But that doesn't mean I should spend paragraphs ripping it to shreds and therein offending people who like it.

So back to the actual discussion, sorry for my irrelevant tangent.

@Beegle: Yes, a separate level editor. And separate files - but what format should be used? Simply order the data as plane-major, then row(or column)-major, and write each byte sequentially? That's the least efficient way to do it (at least, as far as storage space is concerned). But do we care? Should we aim to fit this on a single floppy? Interesting philosophical questions 😀

The "tiles as letters" editor would certainly work for testing. After that we definitely need a graphical editor. I have one already for my game engine that implements all of the basic, most necessary features (and it could easily be modified to read and write level data in any format) but it's written in QB45 and is rather slow except on Pentium machines and DOSBox, but maybe that doesn't matter if we're developing on modern, fast machines. Note: it would be awesome to have a terrain editor built in 😀

I don't know about having a separate collision layer. I feel like it adds an unnecessary level of complexity to the engine, but maybe I'm wrong. I don't know how platform games other than Keen (which simply uses tile properties) do it.

keenmaster486 wrote:

I don't know about having a separate collision layer. I feel like it adds an unnecessary level of complexity to the engine, but maybe I'm wrong. I don't know how platform games other than Keen (which simply uses tile properties) do it.

I have trouble explaining it properly, but I'll give a technical example.

Let's say we have a collision layer separate from the visuals.
We would need only a few basic collision tiles to do 90% of our work. For example :

1_ ground
2/ slope to the right
3\ slope to the left
4| wall
5¯ ceiling

Now let's say we want to have different materials
... grass
... brick
... asphalt
... leaves
... wood
... marble
... tiles
(and more)

if we code the behavior directly in the visual object or tile, for each type of tile, that will be a lot of duplicate code. Or maybe, calls from a large array of tiles going to the same behavior. And lastly, doing it this way is prone to mistakes if we update the slope upwards behavior, but forget to update it on one of the tiles, or whatever.

So let's say that we have 5 types of collision behaviors.
If we separate the collision, that is 5 places to edit if we want to change something in the character's behavior. Adding, changing or removing visual tile sets (let's add glass floors!) will not enlarge that number.

But let's say that we have 5 types of collisions, but they are saved within each type of material, for each angle.
And if we have for example 10 types of materials for the grounds/walls (wood, leaves, asphalt, etc.)
That makes 50 places to keep track of, and maybe update, if we decide to add, change, or remove a visual tile set, or update a behavior. That's many places (grass slope up, concrete slope up, wood slope up, etc.) referring all to the same behavior anyway.

Another technical aspect, is that in my experience having the collision separate, allows many variations of tiles, to share the same behavior. That way we can have basic simple collisions driving the engine, while at the same time having more complex visuals on top. From what I heard in the industry by engineers, that method was lighter and faster to execute at runtime.

A final point on optimizing and compartimenting workflow between people, in this case, design and arts. Let's say we want a slope made of concrete. It could be stairs. It could be a diagonal concrete piece. It could be a fallen concrete floor. But that would be the choice of the artists, not the level designer. The level designer puts a sloped collision there, and later on when we "dress up" the levels/maps we decide on the visuals. That way when we are satisfied with the design of a map, we "lock" the collision layer and artists are only able to update the visual layer with their taste.

Hope that explains it better.

keenmaster486 wrote:

@Beegle: Yes, a separate level editor. And separate files - but what format should be used? Simply order the data as plane-major, then row(or column)-major, and write each byte sequentially? That's the least efficient way to do it (at least, as far as storage space is concerned). But do we care? Should we aim to fit this on a single floppy? Interesting philosophical questions 😀

I wouldn't mind having unoptimized data, at least during development.
And for me the size of the game is not that important. Fitting on one floppy, for a VGA game, was not super important in the end with games on 10-12 floppies.

As for the format, I'll let the engineers/programmers make it as they see fit, as they will be the ones building the engine.
On the LD side as long as the editor is user friendly and simple, I have no concerns on the inner workings of the format and how data is saved.

Wouldn't a generic c++ Tile class with a few collider properties fix those issues and remove the need for an extra collision map?
The engine would simply check per frame where the character is, and if he moves into a tile with one of the set collider properties then it refuses to let him pass through, or walk on a slope, fall through ect.
This way you can also have nice behind the tile scene secrets by choosing what tiles have the collider property set or not.
The Level data itself can hold the Tile values and it's as simple as having a single byte or two for everything you need.

One of my favorite dos games, Diggers (Millennium software) stored the level data in a two byte format, first byte was either 0 or 1 to select which of the tile sets were chosen (256 x 2) and the second byte was the selected 16x16 Tile. Very simple and it allowed one to edit the levels relatively easily. One of the very first things I ever programmed was a level editor for that game, but sadly I don't have a copy of it anymore 🙁
I always thought it would be a fun game to recreate with some multiplayer elements to it.

Looking into the engines you could use Allegro version 4.2, along with Open Watcom or DJGPP for easier to use build environments. I don't like the idea of reinventing any wheels, that's an academic exercise and not useful for any team efforts. Unless you were making an Atari 2600 game in which case I would greatly encourage the reinvention of many techniques 😉 you can learn much in the art of bit twiddling from that ancient system, it forces one to think outside the box. (but I digress)

Rather than rewriting any dev tools, go select your favorite tile editor and get busy making some artwork. Settle for 16x16 or 32x32 tiles, be sure to use a 256 color 8-bit pallet with magenta or that pink as the transparency alpha channel ect.

@Keenmaster486
Start describing the platformer vision you've had in great detail to any artists here that can spearhead the Tile development, or if you want to reuse some of those nice surt ones that is fine also.
Depending on how you envision the game playing, dictates how the engine is programmed. Is it a Keen like platformer?

Jepael wrote:

Could you give a short crash course how to get started with OpenWatcom? I downloaded it and can't determine which folder has which stuff. It came with several folders of host OS binaries. Either how to develop DOS code in DOS, or DOS code in Linux?

I've only used the Windows 32-bit environment to create DOS stuff. It comes with a simple IDE, which is basically a project manager. It allows you to add source files to a project, and configure compile/link options, which it will turn into a makefile. If you double-click a file, it can open it in its own editor, or a custom editor that you can configure. I've configured mine for Notepad++, because I don't like the built-in editor.

Basically, after installing it, you should just poke around in the right subdirectory for your OS. Eg, for Windows, all the good stuff is in the binnt directory. I believe binl is for linux.
binw is for DOS, but iirc requires a 386 or higher to run (I can't use it on an 8088 at least). You can find stuff like WD.EXE there, which is the debugger. I don't think there's an actual IDE there, apart from the VI.EXE that is bundled. But you can find the compiler, assembler, wmake and that sort of stuff.

OpenWatcom also comes with some good documentation in PDF format, describing all sorts of details about special segmented memory features, DOS/BIOS support routines, inline assembly (the 'AUX' feature is rather unique, and may be useful) etc.

As fun as it would be to write something from scratch, having some modern advances like Box2d would be super convenient for physics / collision detection / callback/delegates-based coding that makes game programming a lot easier.

There's an implementation of Box2D for Allegro, not sure if it works or is any good;
https://code.google.com/archive/p/dickbox/sou … /default/source

As far as VGA/EGA - You'd be talking about everything from a 386+ being able to use mode 13h (MCGA). 320x200 at 256 colors out of the box. Pretty decent for a DOS game, and the programming is super easy, no bank-switching like ModeX, EGA, etc..

If you'd ever actually DONE that kind of programming back in the day, you'd cringe at the idea of doing it again 😀 If not, pick up a copy of "Zen of Graphics Programming" by Mike Abrash - and see what's involved. ModeX is AWESOME. But do yourself a favor and make your life easier, at least for v1.0 of this thing.

Also that kickstarter is not quite relevant because it's just a 90's-style platformer for modern PC's, xbox, ps3, etc.. It's not a DOS game.