pouët.net

The second Byterapers oldschool PC demo started up the fire on me and I wanted to ask questions.

Which C compiler for DOS would be better?
I have used DJGPP in the past for Atsou.
I don't know about the others.

I want one with nice easy way to integrate assembly routines in C code.
Something like an #asm #endasm directive to put your code inside. (Ok,. I am used to this with PhrozenC on the CPC, haha). Or isn't it a good practice?

I think DJGPP used cwsdpmi for protected mode. What about the others? (I might have Borland C installed in my old DOS laptop but haven't tried it yet).

Finally, for the recent byterapers DOS demos, which tools were used? Is it C code intermixed with asm or pure asm? In the past I would go for pure asm especially for a 286/386 demo but then I thought, even on CPC I used a C compiler recently to have good structure plus asm for the real stuff, so why not do it here too?

Any other dudes trying to make an oldschool PC demo?

In them good old days, many used the WATCOM compiler with TRAN's PMODEW header.

Borland made a good C compiler. Or else, you can build demos on Visual C too with maybe a good framework.

watcom +1

sure was the defacto standard, asm integration is a bit different than __asm { bla } though (not necessarily a bad thing in this case)

regarding the (B) demo, it's most likely C + asm, as has been most of the time in the past.

And yes, just yesterday I worked on a new texmap polyfiller - but most likely this will be for some hires windows+mmx stuff..

Ah yes, Watcom.
I hope they fixed their compiler errors, though :)

Haven't really used it after, oh I don't know, v11.0 or something. It's called OpenWatcom now, so I'm sure the open-source community has done some AMAZING THINGS with it, as they always do.

sagacity: sarcasm already?

http://openwatcom.org/. Go already.

optim: i used watcom c/c++ in the past. well. another option is to make software demos for windows if you dont like the fact that dos demos dont work in windows unless you want to run it in dosbox, which for someone is not always an option to do.

Hi.

Because those Byterapers 486 demos are 95% coded by me I think I have to answer to this post.. :)

Byterapers 486 demos are compiled with OpenWatcom. Demo engine is C based but all time critical effects are coded with inline-assembler. Watcom inline assembler is very nice from optimization point of view but kind of pain in the arse to code. Mostly because you have to place the assembler code to .h files and report manually what registers are changed in the asm code. But when it is done right then performance is very good.

Dos32x extender is used instead of DOS4gw what is default in Watcom. Please note that OpenWatcom do have dos32a/x with the installer but it is very old version and should be upgraded.

We also have some self made tools to generate optimal palette and for making tons of different precalc arrays. Like sin, cos and light behave arrays. And of course there is one tool to convert 3D object to our fixed point 3D system. Demo doesn't use FPU during play.

byte.b file is actually kad file. That is kind of a file system in a file. That is quite nice because code can find file with its original name and that makes scripting much easier.

Demo engine itself follow script and some overlay/backgroud/timing stuff can be done just by changing the script file. There is also some multitasking done with timers and palette flash can be run in 70fps even when effect itself is running in much lower fps.

3D engine is fixed point engine. 3D coordinate system uses 16.16 fixed point and the actual filling and particles are drawn in 24.8 system. There is no z-buffer so fillings are sorted form back to front. And also note that in the Vanility demo water part the 3D object is really cut in half in real time. 3D object change it form and poly count on the fly...

like look at the tinyptc code to use like a wrapper and blit the buffers on screen. even if its directdraw7 or something, u can probably just look in directx code and find new routines for doing just that. maybe the tinyptc is old and slow i dont know. i still have some old dxblitter routines that i use in my software rendered demos.

DJT: Well, yes. But I have to say I do appreciate Watcom's open-sourcing of the thing. That was actually very decent of them.

Still, what about clang?

@Bera: Thanks, it's very interesting. Another question. What do use for music player in DOS?

@ruderudy: I was only asking about dos demos in something like a 386/486. For Windows software rendering stuff I use SDL and it's fine. Although I don't know how it would perform in a Pentium 1/2 system with windows.

In Vanility we used Synthetic Audio Library (SEAL). But there is a lot of other players available. Midas Sound System is probably the most used sound library in DOS games and demos.

watcom c/cpp, pmodew or dos32, tasm, midas sound system or something comparable. hook up a well equipped 486 and have a go at it.

i thought you were from that period of time optimus :)

"Any other dudes trying to make an oldschool PC demo?"

Me, but I'm going well below what the PC demoscene started -- my experiments are on 4.77MHz 8088, using only CGA or Tandy/PCjr modes. No time this year for coding, but next year I hope to do a PCjr demo.

My environment is Turbo Pascal with inline and linked ASM. I have started toying with OOP in TP (made music engine easier) but it's important to make copies of object vars before doing your ASM inline because otherwise you have to make Self^.anotherDamnPointer^.var references inline which suck ass for speed. I probably won't do this in the future.

My rotozoomer code is here if you're curious: ftp://ftp.oldskool.org/pub/misc/HRN-TTRO.ZIP

@Bera: Any reason why coordinate system is 16.16 but drawing is cast to a 24.8 system?

(There is probably a really good reason, but I don't have access to SHR EAX,8 so the answer is eluding me for now)

Watcom C++, Dos4GW, Midas and a VESA-library for going 32bit (if needed :)

trixter wrote:

I'm pretty sure some of the sorcerers' stuff might have run on a 8088. =)

Trixter: I think your efforts may be considered a step or two more oldschool than others' :)

16.16 fixed point system gives good decimal resolution for example to sin and cos arrays. 1.0 is 65536 in 16.16 system and only 256 in 24.8 system.

However. When coordinates are projected to the screen there is no need to have that much of sub-pixel accuracy. But sometimes, when point is near camera in depth it is projected far outside viewing area. Of course point outside screen is not displayed but triangle borders should point that way. So it would be catastrophic glitch if some coordinates would flip over maximum to the other side of screen...

@rasmus suggest that you could use vesa and truecolor modes. Hmm.. I don't think so. 1991 486 is SLOW. ISA bus can't even allow software scrollers because not even 8-bit MCGA picture can't be send to screen in full fps. There is a reason why 1991 486/ISA is oldskool hardware in the Assembly and P90/PCI is not.

Optimus : you should use adlib/opl2 for the music, anyway :)
And +1 for watcom too. I didn't use it much, but still it's the one that was more easy to work with under dos/win3.11. And the open-source version should allow you to cross-compile from a powerful modern machine if you want so, too.

bera, i didn't see him mentioning 486 anywhere. however, a 486dx should be ok for 32bit.

Hmm. I was under impression that ET4000 or somesuch kewlcool scenercard could blit in a frame.. but maybe those came later.

Oh well. My fucking integrated pieceofshit certainly couldn't. (Hell, it wouldn't even keep up with the much older video7 I had in the 286..)

Was I the only one who did hardware acceleration with s3 864 etc? =)

tseng labs et4000
i used to had one of those. remember that funny 'l' char in the default system font? ;)