1. Sprite & Screen techniques & EU Games
Finally the list-serv is awake again from its winter sleep. Good Morning
all. 8-)
A few things,
1) I think Packard's new game looks great, another proof that the game
art itself makes more difference than the graphics engine itself. And I
can't wait to see it.
2) Some of you would like to make their own game, and get stuck on all
kinds of problems. They could use of the many engines available, but which
?, well here's my list: (With the new ModeX as the winner)
Mode 19-Library by Hollow Horse SoftWare: Well, is your game
only mode19, and you hate ModeX this is your choice for now. It's fast, very
fast. But it doesn't offer any sprite managing, controlling, and you need to
understand the basics of virtual screens & sprites. Maybe some1 can write a
nice tutorial on this, maybe you could buy Michael Packard's Oidzone + game
reference book. It should be good enough to help you through the way you use
their graphics engine. But I really dunno, I haven't seen the book. I said
if you hate ModeX, read below why...
My NextGFX, don't mess with this, its just for those who also
want to write a graphics engine, to play around with the stuff I already
have. Not to be used yet. (really only for those interested to see my code
done)
The virtual screen library of Jiri, well it contains the basic
of virtual screens, and has a very nifty feature, that is most polygram and
basic drawing routines are also available for the virtual screen, this
should be handy to some out their. His routines are very very fast for a
high-level language programmed drawing routines. Only ASM code programmed
with the same algorithm will beat its speed. (like the built-in routines
prolly, but they only work on the real screen) It does not do any (real)
sprite en screen managing. IE compared to other engines, but I don't think
this was his goal anyway. Not for sprites and general game programming, but
you do need to use this engine if you want to use the basic graphics
routines on the virtual screens. Mode19 specific.
My old GFX routines (Irv's FTP, not the EU homepage), well it
isn't totally tested and doesn't use EMemCopy, and it doesn't support ModeX.
But it's speed should not be underestimated, although it is complete
optimized for a P60, on slower machines the routines will be slower than
other engines available. On the faster systems it still has its place, as it
comes to speed. Especially because most engines don't use EMemCopy to its
full extend (command lists).
This prolly changes with EU2 because it supports poke4 which
will make a *big* difference (I think) with the graphics engines that use
EMemCopy. (when those engines are update to use Poke4 off course)
One real benefit of this engine is its flexibility and that it
does sprite managing, only the collision detection isn't available. It will
work with any video mode, (except ModeX), and its has a very high-end
interface. It handles all the sprite stuff, wait retrace, all the scrolling,
and screen cutting for difference type of virtual screens of difference
sizes. (I'm not sure, But I believe the mode19 lib by Hollow Horse software
also supports scrolling, but I'm not sure). It manages your sprites movement
(in degrees or by setting an x-step and y-step) and sprites moving (in a
certain direction with a certain speed), animation (different states of a
sprite, with their own animation method and frames), etc.
It uses compressed sprites which are relatively fast on fast
machines, but relatively slow on slow machines compared to other engines.
(So if you game won't run on slow machines anyway, this could be the right
choice)
Their is only 1 downside, I provided no documentation, and I am
not intended to do this. Well if you ask me, I could tell you basic part you
need to know.
The ModeX lib by Pete Eberlein (the new one) is just one-word:
the BEST, it uses the concept of command lists, which give you an overhead
of about nothing, it has everything in ASM, it has a nice interface(after
you get the hang of it), and it manages palettes, finally, something all
graphics engines lack. It supports custom sizes virtual screens (only my
old, and very slow compared to this GFX also supports this). You can use the
standard libraries provided by Euphoria for many graphic things, because
pixel and getpixel are redefined. And its command interface with methods is
GREAT. Because it's ModeX you have the fastest scrolling ever also!
Producing a game with this engine is the best choice for you all, from
beginner to experienced programmer. His routines are general enough to lack
the support of sprite managing. Simple because you could also use his
routines for a windows GUI, or a font system. (Or a text editor, eh.. David
Cuny).
To those of you who don't know what ModeX is, well it's a hacked
mode 19 actually. So you can have 320*200 resolution, but also any
resolution upto 400*600. Even 320*240 which has pixels of a perfect square,
something very interesting for rotation actually. The is very nice for those
who think SVGA is too slow, and 320*200 is too ugly. 400 by 300 is a very
good resolution for games. Every pixel is a square just like with 320*240,
but it is a better compromise between speed and quality.
Maybe his next project is an high-end layer for game programming. (I
have some great ideas, ask me!)
Just one suggestion to make this more complete: For ModeX no (fast)
line and polygon routines are available, not for the planed virtual screens
as for the real screen. Maybe you can with the help of Jiri add this feature
to you library, Pete. So it's really a generic ModeX library.
It simply destroys all engines here. (Thanx 8-)
3) Their still isn't any MODULE player available for Euphoria, nor Midi
(yak). I did found a completely ASM module player. I suppose this could
easily be Euphorianised using Pete's ASM.E. It should be very fast player
(100% ASM), although it doesn't use the algorithm of ?? , that is suppose to
be very fast. You can find it when searching for SWMP, because I kind of
deleted the ASM code of my HD. (It has predone libs for C and Pascal) I
attached the asm.doc file describing how you could use it in any language
using inline ASM. (or Pete's ASM.E)
4) What could make a world of difference is .LIB support, to those who
dare to try to make this, I've attached a file describing the structure of a
.LIB file. It seems it's just machine code, where we have to poke a few
values in as arguments and maybe set a few registers or something. Please
machine level people, have a look at this, it should be that hard.
5) When can we expect a beta, Robert ? Their are so many bugs in the
Alpha release, maybe an Euphoria 2 Alpha 2 would be nice, so we at least
could work with pointers. And you can concentrate on other not so important
bugs. (Important is the constant bug reported and the routine pointers, I'm
already addicted to them)
6) I'm sorry this one is so long 8-(
7) I hope every1 will have a nice Christmas holiday.
Ralf.
begin 666 Asm.doc
M;&4@4&QA>65R(%8Q+C0 at (" @(" H8RD at ,3DY-"PQ.3DU(&)Y($QO<F0@17AC
MQ,3$Q,3$Q,3$Q,3$Q,3$Q,39#0H-"@T*#0H@(" @(" @(%5324Y'(%1(12!3
M5TU0($12259%4E,@5TE42"!455)"3R!!4U-%34),15(-"B @(" @(" @Q,3$
MQ,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q T*(" @
M(" @(" H;W(@86YY(&]T:&5R(&QA;F=U86=E(&%L;&]W:6YG(&EN;&EN92!A
M<VT@:6YS=')U8W1I;VYS*0T*#0H-"B @(" @(" @($9I<G-T('EO=2!H879E
M(" @(" @("!&:6QE<R!Y;W4@;F5E9"!I;B!A;GD@8V%S92!A<F4Z#0H-"B @
M(" @(" @("!30BY$4E8 at (" @(" @.B!3;W5N9$)L87-T97(@9')I=F5R(" @
M(" @6R R,BXR(&M(>B!M;VYO(" @("!=#0H@(" @(" @(" @4T)0+D125B @
M(" @(#H@4V]U;F1";&%S=&5R(%!R;R!D<FEV97(@(%L@,C$N-R!K2'H@<W1E
M<F5O(" @70T*(" @(" @(" @($=54RY$4E8@(" @(" Z($=R879I<R!5;'1R
M85-O=6YD(&1R:79E<B!;(#0T+C$@:TAZ("MS=&5R96\K(%T-"B @(" @(" @
M("!-3T103$%9+DQ)0B @.B!405--(&QI8G)A<GD@=&AA="!H;VQD<R!A;&P@
M9')I=F5R<PT*(" @(" @(" @($U/1%!,05DN24Y#(" Z(&EN8VQU9&4@9FEL
M92!F;W(@36]D4&QA>2Y,:6(-"@T*(" @(" @(" @5&AE(')E<W0@87)E(&5X
M86UP;&4@9FEL97,L('=H:6-H(&-A;B!B92!I;7!O<G1A;G0@=&\-"B @(" @
M(" @=6YD97)S=&%N9"!T:&EN9W,@8F5T=&5R+@T*#0H-"B @(" @(" @($EN
M9"!T:&5N(&QO860@;VYE#0H@(" @(" @(&]F('1H92!D<FEV97)S(&EN=&\@
M4D%-("AM=7-T(&)E(&$@<&%R86=R87!H(&%D9')E<W,I+B!3;R!Y;W4-"B @
M(" @(" @<&5R:&%P<R!W:6QL(&)E(&%S:VEN9R!A="!P<F]G<F%M('-T87)T
M('=H:6-H(&1R:79E<B!T;R!L;V%D+@T*(" @(" @("!!9G1E<B!H879I;F<@
M=F5R#0H@(" @(" @(&)Y(&1O:6YG(&9A<B!C86QL<R!T;R!I=',@9FER<W0@
M861D<F5S<R H9')I=F5R7W-E9VUE;G0Z,# P,"DN#0H-"B @(" @(" @($YO
M;G0@,C%H+ T*(" @(" @("!S=6)F=6YC=&EO;B T.&@N(%1H97)E9F]R92!Y
M;W4@:&%V92!T;R!A9&IU<W0@>6]U<B!O=VX@;65M;W)Y#0H@(" @(" @(&-O
M;&]C(&UE;2!F;W(@=&AE#0H@(" @(" @('-O=6YD9FEL97,A#0H-"B @(" @
M(" @($-O;G9E;G1I;VX@:7,@=&AA="!T:&4@<F5G:7-T97(@0E@@8V]N=&%I
M;G,@=&AE('-U8F9U;F-T:6]N#0H@(" @(" @(&YU;6)E<BP@861D:71I;VYA
M;"!P87)A;65T97)S(&%R92!P;&%C960@:6X@05@L0U@L1%@@971C+@T*(" @
M(" @("!4:&4@9F]L;&]W:6YG('-U8F9U;F-T:6]N<R!A<F4@879A:6QA8FQE
M(" @(" @0E@],"P@0U@L1%@]8V]N9FEG=7)A=&EO;@T*LR @(" @(" @(" @
M;F0@1%@N#0JS(" @(" @(" @("!#;VYF:6=U<F%T:6]N(&9O<B M4V]U;F1"
M;&%S=&5R.B @(" @($-,/4E242!.54U"15(L($-(/3$-"K,@(" @(" @(" @
M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @1%@]0D%3
M12!!1$1215-3#0JS(" @(" @(" @(" @(" @(" @(" @(" @(" @(" M4V]U
M#0JS(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @
M(" @(" @($18/4)!4T4@041$4D534PT*LR @(" @(" @(" @(" @(" @(" @
M(" @(" @(" @+4=R879I<R!5;'1R85-O=6YD.B!#3#U'1C$@25)1+"!#2#U-
M241)($E240T*LR @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @
M(" @(" @(" @(" @("!$6#U"05-%($%$1%)%4U,-"K,@(" @(" @("T^(%)E
M='5R;G,@05@]9')I=F5R('9E<G-I;VX@:68@<W5C8V5S<V9U;"P@96QS92 P
M+ at T*LR @(" @("!.;W1E.B!)9B!T:&4@9')I=F5R('=A<R!I;FET:6%L:7IE
M9"!C;W)R96-T;'DL(&ET($A!4R!43R!"12!#3$]3140-"K,@(" @(" @(" @
M(" @870@<')O9W)A;2!E;F0@=7-I;F<@<W5B9G5N8W1I;VX@(S$N#0K #0K:
MQ,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$#0JS(" @(" @($)8
M/3$-"K,@(" @(" @(" @($-L;W-E(&1R:79E<BP@<W1O<"!P;&%Y:6YG+"!P
M=70@<V]U;F1C87)D(&EN(&$@<V%F92!S=&%T92P-"K,@(" @(" @(" @(')E
M<W1O<F4@86QL(&EN=&5R<G5P="!V96-T;W)S(&5T8RX-"L -"MK$Q$Q/040@
M34]$54Q%Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$
MQ,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,0-"K,@(" @(" @0E@],BP@1%,Z
M1%@]9FEL96YA;64-"K,@(" @(" @(" @(%-T;W @86YY('-O=6YD(&]U='!U
M"K,@(" @(" @(" @(&AA<R!T;R!E;F0@=VET:"!A('IE<F\@8GET92X@1&]E
M<R!N;W0@<W1A<G0@<&QA>6EN9R!T:&4@<V]N9RX-"K,@(" @(" @+3X@4F5T
M9G5L+"!E;'-E('IE<F\N#0K #0H,#0K:Q,135$%25"!-3T153$7$Q,3$Q,3$
MQ,3$Q,3$Q,3$Q,3$#0JS(" @(" @($)8/3,-"K,@(" @(" @(" @(%-T87)T
M('!L87EI;F<@<')E=FEO=7-L>2!L;V%D960@<V]N9RX-"L -"MK$Q%-43U @
M34]$54Q%Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$
MQ,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,0-"K,@(" @(" @0E@]- T*LR @
M(" @(" @(" @4W1O<"!A;GD@<V]U;F0@;W5T<'5T(&%T(&]N8V4N#0K #0K:
MQ,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$#0JS(" @(" @($)8
M/34L($%,/79O;'5M90T*LR @(" @(" @(" @0VAA;F=E(&UA:6YV;VQU;64N
M(%9A;&ED('9A;'5E<R!A<F4@8F5T=V5E;B P("AL;W=E<W0I(&%N9 T*LR @
M(" @(" @(" @-C0@*&QO=61E<W0I+@T*P T*VL3$4U1!5%53Q,3$Q,3$Q,3$
MQ,3$Q,3$Q,3$Q,3$Q,3$Q T*LR @(" @("!"6#TV#0JS(" @(" @(" @("!'
M970@9')I=F5R)W,@<&QA>6EN9R!S=&%T=7,-"K,@(" @(" @("T^(%)E='5R
M"L -"MK$Q$=%5"!03U-)5$E/3L3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$
MQ,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,0-"K,@(" @
M(" @0E@]-RP@04P], T*LR @(" @(" @(" @1V5T('!L87EI;F<@<&]S:71I
M;VX@*'1O('-Y;F-R;VYI>F4@9W)A<&AI8R!E9F9E8W1S*2X-"K,@(" @(" @
M("T^(%)E='5R;G,@04@]4&%T=&5R;DYU;6)E<BP@04P]3&EN94YU;6)E<B H
M05@],"!I9B!N;W0@<&QA>6EN9RDN#0K #0K:Q,13150@4$]3251)3T[$Q,3$
MQ,3$Q,3$Q,3$Q,3$Q,3$#0JS(" @(" @($)8/3<L($%,/#XP#0JS(" @(" @
M(" @("!3970@<&QA>6EN9R!P;W-I=&EO;BX@5F%L=64@:6X@04P@:7,@861D
M960@=&\@8W5R<F5N="!P;&%Y97)S#0JS(" @(" @(" @("!P871T97)N('!O
M<VET:6]N+B!9;W4@8V%N;F]T('-T97 @8F5L;W<@9FER<W0@86YD('!A<W0@
M;&%S= T*LR @(" @(" @(" @<&%T=&5R;BX@4F5A<V]N86)L92!V86QU97,@
M87)E(#$@;W(@+3$@*#!&1F@I+@T*P T*VL3$4$5!2U/$Q,3$Q,3$Q,3$Q,3$
MQ,3$Q,3$Q,3$Q,3$Q T*LR @(" @("!"6#TX+"!%4SI$23UP96%K(&)U9F9E
M<@T*LR @(" @(" @(" @0V]P>2!T:&4@=F]L=6UE('-E='1I;F=S(&]F(&5A
M8V@@8VAA;FYE;"!T;R!P96%K(&)U9F9E<BP@=VAI8V@-"K,@(" @(" @(" @
M(&AA<R!T;R!H;VQD(&$@;6%X:6UU;2!O9B X(&)Y=&5S+B!4:&4@;G5M8F5R
M(&]F(&-H86YN96QS(&ES#0JS(" @(" @(" @("!K;F]W;B!A9G1E<B!S=6-C
M97-S9G5L(&QO860@;V8@;6]D=6QE9FEL92 H<W5B9G5N8W1I;VX@(S(I+@T*
MQ,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q T*#0H-"B @(" @
M(" @($%L;"!R96=I<W1E<G,@=VEL;"!C;VYT86EN('1H92!S86UE('9A;'5E
M(&%F=&5R(&$@<W5B9G5N8W1I;VX-"B @(" @(" @8V%L;"P@97AC97!T($%8
M"B @(" @(" @>F5R;R!I9B!T:&4@8V%L;"!W87,@<W5C8V5S<V9U;"X-"@T*
M(" @(" @(" @57-I;F<@=&AI<R!C;VYV96YT:6]N<R!Y;W4@8V%N(&QI;FL@
M=&AE(&1R:79E<G,@:6X@86YY#0H@(" @(" @('!R;V=R86UM:6YG(&QA;F=U
M86=E+"!T:&%T('-U<'!O<G1S(&EN;&EN92!A<W-E;6)L>0T*(" @(" @("!I
M;G-T<G5C=&EO;G,N#0H-"B @(" @(" @(%1!4TT@=7-E<G,@8V%N(&AA=F4@
M=&AI;F=S(&$@;&ET=&QE(&)I="!E87-I97(L(&EF('5S:6YG('1H90T*(" @
M(" @("!L:6)R87)Y($U/1%!,05DN3$E"+B!9;W4@:G5S="!H879E('1O(&%D
M9"!T:&4@<W1A=&5M96YT#0H-"B @(" @(" @(" @($E.0TQ51$4@34]$4$Q!
M62Y)3D,-"@T*(" @(" @(" @:6YT;R!Y;W5R(&%S;2!S;W5R8V4@86YD('1H
M92!D<FEV97)S('!L=7,@82!F=6QL>2!A=71O;6%T:6,-"B @(" @(" @:&%R
M;R!N97<@<')O8W,-"B @(" @(" @8V%L;&5D#0H-"B @(" @(" @(" @($UO
M9%]$<FEV97(@(" @(" Z(&=E;F5R86P@9F%R(&-A;&P@861D<F5S<R!T;R!D
M<FEV97)S#0H@(" @(" @(" @("!-;V1?16YD7U-E9R @(" @.B!F87(@<')O
M8R!T:&%T(')E='5R;G,@;&%S="!S96=M96YT(&EN(&%X#0H-"B @(" @(" @
M=2!D;R!N;W0@:&%V92!T;PT*(" @(" @("!L;V%D(&1R:79E<G,@:6YT;R!M
M(" @(" @(&]N;'D@=&AE(&9I<G-T(&9U;F-T:6]N(&ES(&%L=&5R960@<VQI
M9VAT;'D@8V]N=&%I;FEN9R!N;W<@=&AE#0H@(" @(" @(&]P=&EO;B!T;R!C
MQ,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q,3$Q T*LR @(" @("!"6#TP+"!!6#US;W5N
M9&1E=FEC92 H0U@L1%@]8V]N9FEG=7)A=&EO;BD-"K,@(" @(" @(" @($EN
M6#TP(&$@9&5T96-T:6]N#0JS(" @(" @(" @("!W:6QL(&1E8VED92!W:&EC
M="X-"K,@(" @(" @(" @(%1H:7,@<VAO=6QD('=O<FL@:6X@;6]S="!C87-E
M<RX@0G5T('EO=2!H879E('1H92!O<'!O<G1U;FET>2!T;PT*LR @(" @(" @
M(" @8GEP87-S('1H92!D971E8W1I;VXL(&%N9"!M86YU86QL>2!S96QE8W0@
M86YD('-E='5P('1H92!D<FEV97(N#0JS(" @(" @(" @("!);B!T:&ES(&-A
M<V4-"K,@(" @(" @(" @(" @($%8/3$@<W1A;F1S(&9O<B!3;W5N9$)L87-T
M97(@9')I=F5R#0JS(" @(" @(" @(" @("!!6#TR(" @(B @(" @(B @4V]U
M;F1";&%S=&5R(%!R;R!D<FEV97(-"K,@(" @(" @(" @(" @($%8/3,@(" B
M(" @(" B("!'<F%V:7,@56QT<F%3;W5N9"!D<FEV97(-"K,@(" @(" @(" @
M=6ER960@8GD@=&AE(&-O;6UO;@T*LR @(" @(" @(" @9G5N8W1I;VX@(S N
M#0JS(" @(" @(" M/B!2971U<FYS($%8/61R:79E<B!V97)S:6]N(&EF('-U
M8V-E<W-F=6QL+"!E;'-E('IE<F\N#0K #0H@(" @(" @("!4:&4@<V5C;VYD
M05@@=&AE#0H@(" @(" @(&QA<W0@<V5G;65N="!A9&1R97-S(&]F('1H92!P
M;&%Y97(@=&\@=VAI8V@@>6]U(&-A;B!A9&IU<W0@=&AE#0H@(" @(" @(&UA
M:71I86QI<V%T:6]N#0H@(" @(" @(&-O<&EE<R!T:&4@<V5L96-T960@9')I
M=F5R('1O('1H92!L;W=E<W0@<&]S<VEB;&4@;65M;W)Y#0H@(" @(" @(&QO
M#0JS(" @(" @(" M/B!2971U<FYS($%8/61R:79E<B!E;F0@<V5G;65N=" H
M=6YU<V5D*0T*LR @(" @($YO=&4Z($]N;'D@8V%L;"!T:&ES('!R;V,@869T
M97(@:6YI=&EA;&ES871I;VXA#0K #0H@(" @(" @("!4:&5R92!I<R!A;'-O
M=&AE#0H@(" @(" @('5S92!O9B!T:&ES(&QI8G)A<GDN($ET(&ES(&-O9&5D
M(&EN('9E<GDL('9E<GD@96%S>2!A<W-E;6)L97(N#0H@(" @(" @($]F(&-O
M('=O=6QD;B=T#0H@(" @(" @(&UA:V4@=&AE('-O=7)C92!M;W)E(')E861A
M8FQE+@T*#0H-"B @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @
J(" @(" @(" @(" @("!,;W)D($5X8V5S<R!I;B!*=6YE("<Y-0T*&@T*
`
end
2. Re: Sprite & Screen techniques & EU Games
Seasons Greetings,
In response to Ralf's comments about my mode X library, it would seem that
I won't be needing a sales staff with Ralf around to voluntarily promote my
work 
In my opinion, every program should be written with a specific graphics
mode in mind, and use an appropriate graphics library. I think it would be
better to use a library that is fast and has a lot of features limited to a
single mode than use one that runs slow but supports every mode. With all
the libs out there, someone should take a look at each and compare them,
list features and post the results on a web page or something. This would
make choosing a specific lib to use easier for some people.
On the subject of asm... using third party libraries is a bit tricky
depending are whether the libs are written in 32-bit or 16-bit code. The
docs for the mod player attached to Ralf's post were obviously written for
16-bit programs. Converting to 32-bit asm may not be trivial. I haven't
taken a good look at Microsoft's .lib docs yet, but if those are 32-bit
code, then linking them might be very possible.
As for the discussion on a Descent clone, C.K.L wondered about the author
of the texture mapping demo, yes it was me. Euphoria, with the ability to
link to machine code routines, makes just about anything possible, as long
as you know asm. As I mentioned above, all asm has to be 32-bit to be
compatible with the CPU mode that Euphoria runs under. I think a virtual
reality engine for Euphoria may not be long in coming, as I have seen a lot
of talent displayed so far. Everyone, please keep sharing knowledge and
code, so we all may benefit from it. I'm thinking I need a reference from
Plato's "Allegory of the Cave" right here. I for one have been continually
inspired by stuff I see other people doing, though I have to agree with
Michael Packard - someone finish a game!
--
_____ _____ _____
________ /\ \ /\ \ /\ \
/ \ \ / \____\ / \____\ / \____\
/ _ \____\ / / ___/_ / /____/ / / ___/_
/ / \ |____|/ / /\____\ / \ \ / / /\____\
\ \_/ / / \ \/ / ___/_\ \ \ \ \/ / ___/_
\ /____/ \ / /\ \\/\ \ \ \ / /\ \
\ \ \ \ \/ \____\ \ \ \ \ \/ \____\
\ \ \ \ / / \ \____\ \ / /
\ \____\ \ / / \ / / \ / /
\ / / \ / / \/____/ \ / /
\/____/ \/____/xseal at harborside.com\/____/
3. Re: Sprite & Screen techniques & EU Games
>In response to Ralf's comments about my mode X library, it would seem that
>I won't be needing a sales staff with Ralf around to voluntarily promote my
>work
Your welcome, but I'll review the updated mode19 lib by Hollow Horse
software today.
>In my opinion, every program should be written with a specific graphics
>mode in mind, and use an appropriate graphics library. I think it would be
>better to use a library that is fast and has a lot of features limited to a
>single mode than use one that runs slow but supports every mode. With all
>the libs out there, someone should take a look at each and compare them,
>list features and post the results on a web page or something. This would
>make choosing a specific lib to use easier for some people.
With command lists it makes no difference if you design it for one or more
video modes.
You could one general execute command list and different version of all the
other routines.
Any video mode specific lib will give its routine iD's to a routine in the
general upper layer called "IndentifyNewEmployee" or something.
The routines for every video mode should be very very low. (but all the same
usage over the different video modes)
But have an option for extra methods or actions. (like PanTo in ModeX)
The a generic layer for the sprite and virtual screen managing (don't read:
virtual screen copy routines)
Every graphics mode employee will also have to take care of the virtual
screens.
But those aren't made for every mode, those are in a few libs. Most Video
Mode employees can work with the sequence screen managing (the fastest way
for the built-in graphics modes), mode19 and SVGA can work with an memory
screen library, and modeX has to use its own specific planed memory screen
routines.
I say it is possible with no RUN-TIME overhead, only creating command list
can be a bit slower, because routine pointers seem to slower than a direct
call (Robert! Please make them faster) to a routine.
And off course Euphoria 2 Beta has to finished will you even be able to bind
this stuff, but at the time such an engine is finished, and some1 wrote a
game for it, the beta version will already be available.
>On the subject of asm... using third party libraries is a bit tricky
>depending are whether the libs are written in 32-bit or 16-bit code. The
>docs for the mod player attached to Ralf's post were obviously written for
>16-bit programs. Converting to 32-bit asm may not be trivial. I haven't
>taken a good look at Microsoft's .lib docs yet, but if those are 32-bit
>code, then linking them might be very possible.
Oops, I was thinking 16/32 bit only mattered for compiled machine code. So
that it has to be compiled for 32-bit PM, instead of being written for
32-bit PM.
>As for the discussion on a Descent clone, C.K.L wondered about the author
>of the texture mapping demo, yes it was me. Euphoria, with the ability to
>link to machine code routines, makes just about anything possible, as long
>as you know asm. As I mentioned above, all asm has to be 32-bit to be
>compatible with the CPU mode that Euphoria runs under. I think a virtual
>reality engine for Euphoria may not be long in coming, as I have seen a lot
>of talent displayed so far. Everyone, please keep sharing knowledge and
>code, so we all may benefit from it. I'm thinking I need a reference from
>Plato's "Allegory of the Cave" right here. I for one have been continually
>inspired by stuff I see other people doing, though I have to agree with
>Michael Packard - someone finish a game!
Maybe I should finish my clone (develop a beta version using one of the
graphics engines, preferably yours ?)
Did any1 like its game play, because I know the graphics stink.
I only paid attention to the game play, any comments ??
Ralf
4. Re: Sprite & Screen techniques & EU Games
> Seasons Greetings,
>
> In response to Ralf's comments about my mode X library, it would seem that
> I won't be needing a sales staff with Ralf around to voluntarily promote my
> work
>
> In my opinion, every program should be written with a specific graphics
> mode in mind, and use an appropriate graphics library. I think it would be
> better to use a library that is fast and has a lot of features limited to a
> single mode than use one that runs slow but supports every mode. With all
> the libs out there, someone should take a look at each and compare them,
> list features and post the results on a web page or something. This would
> make choosing a specific lib to use easier for some people.
>
> On the subject of asm... using third party libraries is a bit tricky
> depending are whether the libs are written in 32-bit or 16-bit code. The
> docs for the mod player attached to Ralf's post were obviously written for
> 16-bit programs. Converting to 32-bit asm may not be trivial. I haven't
> taken a good look at Microsoft's .lib docs yet, but if those are 32-bit
> code, then linking them might be very possible.
>
> As for the discussion on a Descent clone, C.K.L wondered about the author
> of the texture mapping demo, yes it was me. Euphoria, with the ability to
> link to machine code routines, makes just about anything possible, as long
> as you know asm. As I mentioned above, all asm has to be 32-bit to be
> compatible with the CPU mode that Euphoria runs under. I think a virtual
> reality engine for Euphoria may not be long in coming, as I have seen a lot
> of talent displayed so far. Everyone, please keep sharing knowledge and
> code, so we all may benefit from it. I'm thinking I need a reference from
> Plato's "Allegory of the Cave" right here. I for one have been continually
> inspired by stuff I see other people doing, though I have to agree with
> Michael Packard - someone finish a game!
How do I write 32 bit ASM? I can write a litle 16 bit. Whats the
diference? Do I need a diferent compiler(I use arrowsoft)?
--PatRat (Thomas Parslow)
-- ()___()
-- (o o)
-- =\O/=
-- RAT OF THE MONTH
-- Competition
