Pictures From London by Slovakia Software
********************************
* --- PICTURES FROM LONDON --- *
******************************** XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Code:Martin Benca XX PLEASE DO NOT COPY XX
Graphics:Martin Benca XX THIS DEMO TO YOUR FRIEND XX
Music Routine:Martin Benca XX WITHOUT THIS LONDON.DOC FILE XX
Sampling:Martin Benca XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1. Introduction
---------------
There was a long, very long time since my last intro release called Slovakia
Blaster Demo. But now there is another one. Picutures from London. Why I
titled it Pictures from London (PFL) is my own secret. Only few friends of
mine knows the reason and I am not going to tell you that. However, name is
not very important.
PFL is much better looking than Slovakia Blaster Demo. The main reasons
are, that it is almost completely written in Assembler, uses very nice
algorithms and has much, much bigger hardware requirements.
2. Hardware requirements
------------------------
This demo will not run optimally on anything worser than Am386DX/40. Because
all sines are precalculated and no 387 instructions are used, there is no
speed difference between 486SX and 486DX. However, demo will run with optimal
speed on any 486, so don't worry about that.
For nice smooth animation 386/33 is good enough, but only at 7kHz sound
mixing speed, so music is poor. In the begining there is a hardware test.
Altough there are no 386 instructions, program will not allow you to execute
it on a 286, because no 286 has enough computing power for this demo.
Because music is loaded from Hard Disk and there is no DMA usage, for nice
animation you should have disk drive with 20ms or less and 500kb/s transfer
speed. Otherwise, there will be small delays during animation.
For passing the test you must also have enough memory. The memory
requirements are cca. 130Kb without music and 250Kb with music.
IMPORTANT: I accidentally released Beta test version of this demo. This
version has no VGA detection and has much bigger hardware
requirements, because it is not optimized. The difference
between this version and beta test version is in version number.
Beta has 1.00 and this has 1.50. Please, if you'll find 1.00
version somewhere, either delete it or replace with this version.
3. Troubleshoting
-----------------
If demo does not work, there is probably some confilct with previously
installed TSR programs. The solution is simple. Just remove all these
conficting TSR programs before executing Pictures from London. The second
most common problem is in EMS memory allocation. If you have in your
Config.Sys something like this: DEVICE=Emm386.Exe I=B000-B7FF, demo will
not run properly, because it needs B000h-BFFFh adressing area. So, you have
to remove this part of line. You can still use EMM386, but remove that
I=B000-B7FF. However, if you haven't 486 I recomend you to remove whole
Emm386 instalation, because it decreases speed of demo.
If animation isn't smooth and your machine is fast enough, it's possible,
that your disk drive is too fragmentated. Optimize your drive and then try
again (or just realocate this demo file to defragmented area).
If demo still does not work properly, there is probably some low-level
hardware compatibility problem.
4. Techincal details
--------------------
Whole intro is written in TurboPascal, but uses many assembler procedures.
Nice background is calculated by my own plasma creator during initialization.
However, it is stored into memory as bitmap and occupies 64000 bytes of
convetional memory, because I need this points to clear old frames and it is
much faster to get background pixel color from some allocated memory area,
than calculate it again and again for each frame.
VGA palette is not calculated, because calculating routine was longer than
768 bytes, so it was more efficient to store it into file. The bitmap of my
face is also saved here and it occupies 82*97=7954 bytes. A 628 bytes long
sinus table sn:array[0..627] of byte where sn[i]=trunc(sin(i/100)*127+128)
is included too. All this data are linked at the end of london.exe file in
order:
[exe file]+[sinus table]+[palette]+[my photo]+[sampled music]
[17136] + [628] + [768] + [7954] + [946284]
When my program wants to load this data, it gets itself's path+name from
PSP info (paramstr[0]), gets filesize(name) and then seeks file position
seek(filesize-946284-768-628). After that loads sinus table, palette, and my
photo into reserved memory.
The sample length is unlimited. My program is loading new parts of song from
disk during playing, so there is no XMS or EMS usage necessary. There is no
problem to do something like this on SoundBlaster, but my routine works with
LPT ports too, because it doesn't need any DMA channel. As I know this was
coded only in Meciarnator II demo. But Meciarnator II uses directly hard disk
ports, what has two big disadvantages. You can't run it under Stacker or
DblSpace and it is very problematic to imply. Meciarnator II still doesn't
run corectly on all machines. As you can see there is no problem to do it
with using standart INT 21h routines. It just need one small, very simply
idea. You have to allow interrupts after every INT 76h call and then wait
there a bit, before executing standart INT 76h routine. That's the reason why
HD led diode is shining so long.
The demo uses two "video pages" which are switched by using VGA ports
3d4h/3d5h. Altough Miso Weis was talking about impossibility to do it, demo
runs in mode 13H (Some people claims, that you must initialize undocumented
X-mode, because it is impossible to work with more than one video page under
13h on 256Kb VGA. If you are using BIOS, they're maybe right but which true
coder is using BIOS graphic services ?).
I switched memory mapping for CPU to 128K, situated first page at A0000h
and second at B0000h. That allows you very simple page select just by
changing video ram segment adress.
New frame is always written into page which is not on screen. When drawing
is finished, pages are swapped and whole process repeats. That's the solution
how to see just sequence of frames and avoid terrible redrawing.
You probably noticed, that background animation is just palette rotating.
Maybe you'll get some small snow effect, because my setpalette routine does
not wait for vertical retrace due to requesting highest possible speed. On
all machines, where this demo was tested I almost couldn't notice any snowing,
so I consider not neccesary to add this retrace waiting.
Circles in this demo are drawed by my own algorithm which is I think one
of the fastest ever coded. (cca. 30 times faster than standard BGI routine)
It doesn't need any precalculations, multiplying or dividing.
There is also a time control hanged on INT 08h. If you have extremly fast
machine, which is able to draw more than 20 frames per second, a delay is
added. I know, that standart is 25 frames, but at this frequency animation is
too fast and looks horrible. And at last some dimensions:
-Every pipe consists from 21 circles of different radius.
-Waved picture of myself is 82*97 pixels big
-Flames have about 30x40 pixels
5.Optimalization
----------------
Circle drawing, picture waving and playing routines are optimized for the
maximum speed and I have no idea how to do it faster. Flames aren't optimized,
but I think they can't be improved very much too. Calculations of circle
positions aren't optimized (and could be improved) but this routine is taking
only cca. 0.1% of computing time per frame, so it has no importance to final
speed of demo. However if you have debugged this demo and found some ideas how
to radically speed it up (more than 10%) please let me know. (Please don't
bother me with suggestions like store flame frames into bitmap).
Small delay after sound card and sound quality selection is caused by
unoptimized backgroud calculation. I used universal algorithms here (for
example border is drawed by universal line drawing routine), so it could be
done faster, but I was too lazy to optimize this, because this is just some
type of precalculation and has no affect to animation speed.
6. Thanks to other people for support
-------------------------------------
Firstly I'd like to thank to Miso Weis for information how to use SoundBlaster
D/A convertor. My second thank goes to Lubomir Pozgay for scanned photo of
myself, used in this demo. And at last, but not least a big thank goes to
Borland International, for Turbo Pascal, which is really great programming
language (but please add 386 support here in your next version).
7. Lincencion & Source Code
---------------------------
This demo is fully freeware. You can copy it, distribute it, use it for own
comercial or non-comercial purposes, but DO NOT modify it.
If you want to get source code of this demo send 5DM or equivalent in another
currency to my adress and I'll send it to you.
8. Greetings and messages
-------------------------
Triton - I think you are simply the best demo coders in the world.
Will you release Crystal Dream III ? If yes, please don't forget
to support stereo on two ports. Not all people are using
Stereo-on-one.
Future Crew - No matter, what other people are saying, I enyoed Second
reality very much, but why do you not support LPT Dac's ?
They have much better sound quality than SoundBlaster on high
mixing frequences and there are no problems with slow chips. I
know, that GUS is better, but remember, not all people have
enough money to purchase it.
SunRise - Are you going to win Assembly competition next year ? Will you
release your first megademo in 1994 ? (Sorry for these
provoking questions.)
Mark J. Cox - Could you add some info routines into your next release of
Mod-Obj.Obj ? For example some procedure returning which note
on which track is played at the moment. It will help to make
synchronization with music. Will be there next release of
ModPlay Pro, or you stopped developing of this product ?
9. Questions, Questions, Questions
----------------------------------
If you have any questions about this or another products just contact me.
My adress including Email is written at the end of demo. The last part is
written in Slovak language, because it has no importance for foreign
viewers. If you are too curious what is written here I can tell you.
I'm trying to contact with some other Slovak demo coders in this text.
Well, that's all. Have a nice DOS.
Doc. Ing. John Rambo DrSc.
(Martin Benca)
Slovakia Software
P.S. Merry Xmas'93 and happy new year to all coders in the world !!!
[ back to the prod ]