1. Fast graphics and scrolling
> BTW, your demo was very good, but so was the demo of Devilman by
> Liquid-Nitrogen. His background also scrolls very smooth and fast. How
> would he do it, you think? (Don't try to explain me, cause I am quite
> ignorant when it comes to fast graphical routines. The only thing I do is
> look at the demos and ask myself: how do they do this fast scrolling and
> drawing?)
He is using a specialized mode 19 library developed by Hollow Horse
Software
(Greg Harris and Lucius L. Hilley). We plan on releasing a freeware version
in hopefully a few more weeks
to the RDS homepage after a bit more tweaking, debuging and writing some
descent documentation. As to his scrolling methods,
I'll leave that up to him to tell you how that was done :).
Regards,
Greg Harris
blackdog at cdc.net
Hollow Horse Software
2. Re: Fast graphics and scrolling
- Posted by Ralf Nieuwenhuijsen <nieuwen at POP.XS4ALL.NL>
Jul 03, 1997
-
Last edited Jul 04, 1997
> > BTW, your demo was very good, but so was the demo of Devilman by
> > Liquid-Nitrogen. His background also scrolls very smooth and fast. How
> > would he do it, you think? (Don't try to explain me, cause I am quite
> > ignorant when it comes to fast graphical routines. The only thing I do is
> > look at the demos and ask myself: how do they do this fast scrolling and
> > drawing?)
Well, a lot of values need to be calculated but they don't change
often, or they change linear. If you would save your position as
{x,y} as everybody normally does you had to calculate your position
in memory each time with (y-1)*screen_width + (x-1). However if you
save such a fixed position you can just add the screen_width to go
a line down. There are many other tricks also. You should always to
to use as few variables as you can and avoid atom's also how less
statements are executed the faster it is. When you copy one screen to
another and they have both the same size the engine copys it with
only one mem_copy command. When the sizes aren't the same it copies
it line by line. (which slows it down). There are many other specific
situations where the code could do it faster, i allways try to find
them all. Didn't you wonder why it is about 1000 lines (i'll upload
this version in a minute... it's even longer!).
Also you say they both have scrolling background.... NOT!!
He has a fixed background of a fixed size!! (so he can copy it in
once) He has one sprite that uses a poor sprite technique (mine is
about 100 times faster... sorry) and he uses an image technique to
draw the scrolling field... to prove this all. I'll make a version
with real scrolling background and rest will be the same... i'll use
his pictures... then he can look at my framerate, It would compare
easily.
I do not know if his routines are as flexible as mine... they can't
be more flexible as mine. If you change the video mode at the
beginning of your program, the rest will just work as it is supposed
too. This also goes for the different types of sprites, screens.
If he wants too, he can get my sprite technique so he can speed up
his with about 200% (really, change the demo to have 50 sprites, the
frame rate is about 70%, 80% of the one with the 25 sprites...
He scrolls the blocks and cuts them nicely.. (i still have to update
my routines to allow you to display a sprite partly of screen)
My routines (the ones i am gonna upload in a minute) handle blocks
as fast as normal poke routines do (poke is faster if it is used for
less the 87 bytes on my computer). It is only a BIT slower when you
have transparancy in the middle of a horizontal line. There is also
an amount of COMPRESSION when using sprites... which can save a great
deal of memory real time and only IMPROVE its speed!!!!
> He is using a specialized mode 19 library developed by Hollow Horse
> Software
> (Greg Harris and Lucius L. Hilley). We plan on releasing a freeware version
> in hopefully a few more weeks
> to the RDS homepage after a bit more tweaking, debuging and writing some
> descent documentation. As to his scrolling methods,
> I'll leave that up to him to tell you how that was done :).
I am kind of interested in that... :)
Too compare and change what he routines do faster....
After all our interest is to have the fastest graphix routines not
to make routines that are faster than the others......
I am gonna upload the routines now and then rewrite his demo to
compare and then write docs... it is now about 23:17... I got nothing
else important to do this night or next morning.. so you can all play
with it tomorrow....
The things i added with this and the most recent versions:
* Got some bug out.. :)
* Added compression (it is now faster too when drawing)
* Added second WaitRetrace method which is less accurate but a
lot
faster and ussually is good enough
* Image routines... you can use DisplayImageVS() and
SaveImageVS()
To do normal image things on the monitor or on a virtual
screen
FAST!! Using this for the monitor is faster and if your view is set
right (not of the screen thus) you can't poke out of the video
memory.
* Update gfxsafe to only have the memory addres of the current
video mode allowed when there is a video memory.. otherwise none is
allowed.
* A few smalls things at the inside... optimized some loops!!
It will be GFXNEW3.ZIP
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
3. Re: Fast graphics and scrolling
> Also you say they both have scrolling background.... NOT!!
> He has a fixed background of a fixed size!! (so he can copy it in
> once) He has one sprite that uses a poor sprite technique (mine is
> about 100 times faster... sorry) and he uses an image technique to
> draw the scrolling field... to prove this all. I'll make a version
> with real scrolling background and rest will be the same... i'll use
> his pictures... then he can look at my framerate, It would compare
> easily.
I can assure you that he is not using a fixed size background, although it
is possible with the engine.
Using his technique, backgrounds of almost unlimited size can be displayed.
Also he is not using the latest version of the engine in the game. (I just
sent him the latest copy last night) It should increase the frame rate by
2.5x.
> I do not know if his routines are as flexible as mine... they can't
> be more flexible as mine. If you change the video mode at the
> beginning of your program, the rest will just work as it is supposed
> too. This also goes for the different types of sprites, screens.
The routines were not designed to be used in any thing else than 320x200
mode (mode 19). This is to conectrate on speed.
Most of the routines will be converted in assembly soon where needed.
Virtual screens are dynamically allocated and freed. Most all routines can
handle either sequence or memory stored bitmaps.
> He scrolls the blocks and cuts them nicely.. (i still have to update
> my routines to allow you to display a sprite partly of screen)
This is built into the engine, no need to worry about screen boundarys.
> > He is using a specialized mode 19 library developed by Hollow Horse
> > Software
> I am kind of interested in that... :)
> Too compare and change what he routines do faster....
Sorry. The source code will be shrouded when released. The registered
version will be used in a commercial game we are producing.
> After all our interest is to have the fastest graphix routines not
> to make routines that are faster than the others......
Well some of use have other agendas.. :)
Greg Harris
blackdog at cdc.net
4. Re: Fast graphics and scrolling
> > Also you say they both have scrolling background.... NOT!!
> > He has a fixed background of a fixed size!! (so he can copy it in
> > once) He has one sprite that uses a poor sprite technique (mine is
> > about 100 times faster... sorry) and he uses an image technique to
> > draw the scrolling field... to prove this all. I'll make a version
> > with real scrolling background and rest will be the same... i'll use
> > his pictures... then he can look at my framerate, It would compare
> > easily.
>
> I can assure you that he is not using a fixed size background, although it
> is possible with the engine.
> Using his technique, backgrounds of almost unlimited size can be displayed.
> Also he is not using the latest version of the engine in the game. (I just
> sent him the latest copy last night) It should increase the frame rate by
> 2.5x.
2.5x times is needed to be compared to mine and we do not have the
same definition for fixed size background. I ment your background
(the yellow to green scenery BEHIND the walls & objects). That is of
the size 320*200 and it doesn't scroll along. This is considered the
background. These are the pixels that you see-through the objects
(except your none-sprite walls, why not use cool see-through walls,
or can't it handle all those sprite so fast...??)
> > I do not know if his routines are as flexible as mine... they can't
> > be more flexible as mine. If you change the video mode at the
> > beginning of your program, the rest will just work as it is supposed
> > too. This also goes for the different types of sprites, screens.
>
> The routines were not designed to be used in any thing else than 320x200
> mode (mode 19). This is to conectrate on speed.
> Most of the routines will be converted in assembly soon where needed.
> Virtual screens are dynamically allocated and freed. Most all routines can
> handle either sequence or memory stored bitmaps.
Hey, i'm working on SVGA, i only need some docs and help from
somebody who knows assembly well and then i can write 'directly' to
the svga memory using that assembly to copy the stuff weird...
..........hey wait, i'm not gonna tell you this ... you don't want to
share your tricks too...
> > He scrolls the blocks and cuts them nicely.. (i still have to update
> > my routines to allow you to display a sprite partly of screen)
>
> This is built into the engine, no need to worry about screen boundarys.
Depends... do you have one big see-through screen were you change
your view offset or do you move the blocks over a 320*200 virtual
screen. (And thus cutting them nicely)
> > > He is using a specialized mode 19 library developed by Hollow Horse
> > > Software
>
> > I am kind of interested in that... :)
> > Too compare and change what he routines do faster....
>
> Sorry. The source code will be shrouded when released. The registered
> version will be used in a commercial game we are producing.
Yeah? Well mine will be free, i always learned from other people's
free code, so did eveybody. Together and with everybody's help i'll
make the best possible without charging them money afterwards to play
the game they helped design. You do it all by yourself, with the risk
of doing something wrong or just not most optimal.
Well i must warn you.. if i ever catch you peeking into my code you
can't ask money for it.. cause it's freeware.. so you must swear that
you never LOOK at my code... you can run it too see that you code
isn't the fastest (yet, i didn't see your new improved version)
> > After all our interest is to have the fastest graphix routines not
> > to make routines that are faster than the others......
>
> Well some of use have other agendas.. :)
I can get enough help on the mail server.. it will be your problem
mostly.. having a concurrent with free code can be diffecult if your
code isn't at least as good. However i am gonna wipe your ass if you
use any part of my code or techniques unless you can swear on your
mothers life and that of your computer that you didn't use the info i
gave on the mail server, or the info i added too the code, or the
code itself.
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
" a commercial game" ??? You are gonna be rich that's for sure.....
NOT!!!! Platform games on the pc is like pacman on a Nintendo 64.
No you need something ORIGINAL to make money.... (like Diable added
cool multi-player options and dynamically designed levels, or like
Lemmings, Or like Quake giving the best possible 3D graphics)
Your platform will not even be as good as Jazz JackRabbit, a classic
you at least need to defeat can you call your game commercial.....
Well, like i said, more your than mine problem!
Ralf.
5. Re: Fast graphics and scrolling
Ralf Nieuwenhuijsen wrote:
> Hey, i'm working on SVGA, i only need some docs and help from
> somebody who knows assembly well and then i can write 'directly' to
> the svga memory using that assembly to copy the stuff weird...
Ralf, does this mean that your code would not be portable? Would it be
portable with slight changes? What if, say, we wanted to create a game
using your code and wanted PC, Mac, and Amiga people to use it...
Course, then we have to assume, I guess, that EUPHORIA is available for
those platforms.
So, nevermind.
Jus' wonderin',
ck
P.S. You shouldn't let other people get you all riled up. Let your code
speak for itself. It does that pretty well. :)
6. Re: Fast graphics and scrolling
> Ralf Nieuwenhuijsen wrote:
>
> > Hey, i'm working on SVGA, i only need some docs and help from
> > somebody who knows assembly well and then i can write 'directly' to
> > the svga memory using that assembly to copy the stuff weird...
>
> Ralf, does this mean that your code would not be portable? Would it be
> portable with slight changes? What if, say, we wanted to create a game
> using your code and wanted PC, Mac, and Amiga people to use it...
> Course, then we have to assume, I guess, that EUPHORIA is available for
> those platforms.
Yeah, but i'll be saving the assmebly in a special file... it only
has to contain a few routines, that are: WaitRetrace, A MemCopy
command handler (with commands as copy this length then skip this
much and do thid all this many times, next command)
Then it will al be like Jazzy Jack Rabbit speed (PS This game engine
is coded by a Dutch Man too, :))
> So, nevermind.
> Jus' wonderin',
Hey, would i trow away such an option that easily...
PS The file allmodes.e should then also be updated, there would be
different screen modes and resolutions... but if an other version of
Euphoria comes out it is done in about a minute!!
> P.S. You shouldn't let other people get you all riled up. Let your code
> speak for itself. It does that pretty well. :)
I didn't. I don't care too much to get all riled up about that.
I don't have too compete with them because as long as mine is free,
i always win!!
I was just trying to help them to kick their but back in reality.
How longer they are hoping to get a lot of money, the bigger the
dissapointment would be. They would at least have some sort of
orginial idea. You can get sprites and virtual screen code in allmost
all langues for free or a real small donation. A better one is found
in a sec. It is just not for Euphoria.
Still don't you all find it cool that my code is THAT portable.
The structure needed for animation and stuff to keep it portable was
gotten from some tutorial that teaches you how to think right.
The example program was a c-3d program, and if you change ONE
setting it would all be protable to win95 - dos - unix - more...
Really cool how they did it.... Duke3D is already very
descrimination in CPU-type ... :(
Still, i don't get 3d, for that, English is just too far from me to
understand it well enough.
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
7. Re: Fast graphics and scrolling
On Fri, 4 Jul 1997 00:51:20 +0000 Ralf Nieuwenhuijsen
<nieuwen at magigimmix.xs4all.nl> writes:
>
>> > Also you say they both have scrolling background.... NOT!!
>> > He has a fixed background of a fixed size!! (so he can
>copy it in
>> > once) He has one sprite that uses a poor sprite technique (mine is
>> > about 100 times faster... sorry) and he uses an image technique to
>> > draw the scrolling field... to prove this all. I'll make a version
>> > with real scrolling background and rest will be the same... i'll
>use
>> > his pictures... then he can look at my framerate, It would compare
>> > easily.
>>
>> I can assure you that he is not using a fixed size background,
>although it
>> is possible with the engine.
>> Using his technique, backgrounds of almost unlimited size can be
>displayed.
>> Also he is not using the latest version of the engine in the game.
>(I just
>> sent him the latest copy last night) It should increase the frame
>rate by
>> 2.5x.
>
> 2.5x times is needed to be compared to mine and we do not have
>the
>same definition for fixed size background. I ment your background
>(the yellow to green scenery BEHIND the walls & objects). That is of
>the size 320*200 and it doesn't scroll along. This is considered the
>background. These are the pixels that you see-through the objects
>(except your none-sprite walls, why not use cool see-through walls,
>or can't it handle all those sprite so fast...??)
>
We, (Hollow Horse, Lucius and Greg) have not created ANY demos.
The demo is entirely MARK's Code. WE created a library of screen
routines that are Greatly faster than HIS original screen
routines. The entire design of the Demo is his.
The scrolling, as you say it, NOT quite background is handle by
some routine(s) that MARK created. It appears HE has bugs in
his scrolling routine(s) somewhere. THIS is not OUR fault.
WE never stated WHAT type of game we will be creating.
>> The routines were not designed to be used in any thing else than
>320x200
>> mode (mode 19). This is to conectrate on speed.
>> Most of the routines will be converted in assembly soon where
>needed.
>> Virtual screens are dynamically allocated and freed. Most all
>routines can
>> handle either sequence or memory stored bitmaps.
> Hey, i'm working on SVGA, i only need some docs and help from
>somebody who knows assembly well and then i can write 'directly' to
>the svga memory using that assembly to copy the stuff weird...
>..........hey wait, i'm not gonna tell you this ... you don't want to
>share your tricks too...
WE know very little about assembly so Neither of us can be of much
help there. WE are helpful, BUT we have worked VERY hard on these
routines and know without a doubt that they MUST be NEAR the fastest
routines possible without going into assembly.
WE do intend to create some assembly code but are not having much
success right now.
>> > He scrolls the blocks and cuts them nicely.. (i still have to
>update
>> > my routines to allow you to display a sprite partly of screen)
>>
>> This is built into the engine, no need to worry about screen
>boundarys.
> Depends... do you have one big see-through screen were you
>change
>your view offset or do you move the blocks over a 320*200 virtual
>screen. (And thus cutting them nicely)
Our screens are fixed at 320*200 we have a clip routine that clips
the IMAGE before passing to a display routine.
>> > > He is using a specialized mode 19 library developed by Hollow
>Horse
>> > > Software
>>
>> > I am kind of interested in that... :)
>> > Too compare and change what he routines do faster....
>>
>> Sorry. The source code will be shrouded when released. The
>registered
>> version will be used in a commercial game we are producing.
> Yeah? Well mine will be free, i always learned from other
>people's
>free code, so did eveybody. Together and with everybody's help i'll
>make the best possible without charging them money afterwards to play
>the game they helped design. You do it all by yourself, with the risk
>of doing something wrong or just not most optimal.
> Well i must warn you.. if i ever catch you peeking into my
>code you
>can't ask money for it.. cause it's freeware.. so you must swear that
>you never LOOK at my code... you can run it too see that you code
>isn't the fastest (yet, i didn't see your new improved version)
We have always given credit where credit is dew.
Just because you think of a design before us doesn't mean one
of us didn't think of it before seeing your code.
I for one have seen or run your code. I simply am not interested.
I feel that it is nearly impossible for your code to be faster &
still be able to offer the flexibility that you imply.
FACT: flexibility hinders speed.
FACT: SOME flexibility is REQUIRED.
I can't speak for my partner on this BUT I have NO intentions on
moveing to ANY screen mode other than 19. IT is the most widely
used mode. It is also the easiest to work with and has great speed
considering what it has to offer. I only regret that it isn't
640*480.
>> > After all our interest is to have the fastest graphix routines not
>> > to make routines that are faster than the others......
>>
>> Well some of use have other agendas.. :)
I feel my partner was a LITTLE harh here. I agree with the fastest
routines theory however I don't feel like sharing all of my secrets.
I don't mind offering a little help here and there. But I have already
release a few routines as freeware and WE feel that these routines are
superb and that they are worth some MONEY. We haven't even decided an
amount yet. WE want to be fair.
> I can get enough help on the mail server.. it will be your
>problem
>mostly.. having a concurrent with free code can be diffecult if your
>code isn't at least as good. However i am gonna wipe your ass if you
>use any part of my code or techniques unless you can swear on your
>mothers life and that of your computer that you didn't use the info i
>gave on the mail server, or the info i added too the code, or the
>code itself.
Tell you what. I will assure you that ME and my partner will not even
get CLOSE to anymore of your code. WE will rely on others to decide
speed factors. NOT that I care. (NOT to gloat but) I wrote several of
the routines. IN Fact MOST of the routines. I KNOW what they are made
off. I KNOW Euphoria's limits. I KNOW that OUR present routines are
Euphoria 1.5a specific. Older versions will not perform fairly.
WE have hinged some of our routines on Robert's improvements.
>Ralf Nieuwenhuijsen
>nieuwen at xs4all.nl
>
>
>" a commercial game" ??? You are gonna be rich that's for sure.....
>
>NOT!!!! Platform games on the pc is like pacman on a Nintendo 64.
>No you need something ORIGINAL to make money.... (like Diable added
>cool multi-player options and dynamically designed levels, or like
>Lemmings, Or like Quake giving the best possible 3D graphics)
>
>Your platform will not even be as good as Jazz JackRabbit, a classic
>you at least need to defeat can you call your game commercial.....
>
>Well, like i said, more your than mine problem!
>
>Ralf.
>
Again Ralf. We never stated what type of game we intend to create.
Loop for my name on The Official Euphoria Programming Page under
Either ARCHIVE or Recent contributions.
--Lucius Lamar Hilley III
-- E-mail at luciuslhilleyiii at juno.com
-- I support transferring of files less than 60K.
-- I can Decode both UU and Base64 format.
8. Re: Fast graphics and scrolling
- Posted by "C. K. Lester" <cklester at FLASH.NET>
Jul 03, 1997
-
Last edited Jul 04, 1997
Lucius L Hilley III wrote:
> WE never stated WHAT type of game we will be creating.
Hey, speakin' of, what type of game are you guys creating? :)
Need a beta-tester? I'm available.
> >> The routines were not designed to be used in any thing else than
> >320x200
> >> mode (mode 19).
How easy/simple would it be to go to 640x480, or higher?
> I don't mind offering a little help here and there. But I have already
>
> release a few routines as freeware and WE feel that these routines are
>
> superb and that they are worth some MONEY. We haven't even decided an
>
> amount yet. WE want to be fair.
Where are these routines, so I might peruse them at my leisure?
Later!
ck
9. Re: Fast graphics and scrolling
- Posted by Greg Harris <blackdog at CDC.NET>
Jul 03, 1997
-
Last edited Jul 04, 1997
> 2.5x times is needed to be compared to mine and we do not have the
> same definition for fixed size background. I ment your background
> (the yellow to green scenery BEHIND the walls & objects). That is of
> the size 320*200 and it doesn't scroll along. This is considered the
> background. These are the pixels that you see-through the objects
> (except your none-sprite walls, why not use cool see-through walls,
> or can't it handle all those sprite so fast...??)
Well first of all, let me say that the Devilman demo was written by Mark
Honnor and not us. He has been helping us to develop our 2D engine and we
give him free right to use our routines. I was talking about the blocks not
the yellow stuff. I have another demo he sent me that uses almost all
blocks and a parallax see thru type effect. The reason that the fps is so
low is that his scroll engine only draws when it has to. The fps counter is
not very accurate. Our engine can handle see thru walls very efficently
with extremely high fps on a 486.
>Hey, i'm working on SVGA, i only need some docs and help from
Were working in VGA
> somebody who knows assembly well and then i can write 'directly' to
> the svga memory using that assembly to copy the stuff weird...
> ..........hey wait, i'm not gonna tell you this ... you don't want to
> share your tricks too...
No need to. We plan on developing a modex library next.
>> This is built into the engine, no need to worry about screen boundarys.
> Depends... do you have one big see-through screen were you
change
> your view offset or do you move the blocks over a 320*200 virtual
> screen. (And thus cutting them nicely)
Actually neither one I guess. We have a routine that handles clipping and
then passes it to the display routines. It does all the out of bounds
checking for you.
> > Sorry. The source code will be shrouded when released. The registered
> > version will be used in a commercial game we are producing.
> Yeah? Well mine will be free, i always learned from other
people's
> free code, so did eveybody. Together and with everybody's help i'll
> make the best possible without charging them money afterwards to play
> the game they helped design. You do it all by yourself, with the risk
> of doing something wrong or just not most optimal.
I believe that I did SAY a FREEWARE version of it will be released and sent
to the RDS homepage. Its FREE, FREE, FREE, FREE (Get the picture?) to use
in a non-comercial applications. We just do not wish to distrubute the
source code. Any help that we received from others, will be recognized in
our readme text and they will recieve a free copy of the engine and
possible the source code. I have tried to help others by releasing code to
the listserver when I can. Any code that I post on here I consider in the
public domain.
> Well i must warn you.. if i ever catch you peeking into my code you
> can't ask money for it.. cause it's freeware.. so you must swear that
> you never LOOK at my code... you can run it too see that you code
> isn't the fastest (yet, i didn't see your new improved version)
Well, I skimmed over it and found it to be less than interesting. I
promptly deleted it from my hard drive. I always ask if I can use someone
elses code before I use it, when at all possible. The only persons code
that we have used is Mark Honnors (Used by permission from the author) and
Pete Eberlein's code that he posted on the listserver.
>I can get enough help on the mail server.. it will be your problem
> mostly.. having a concurrent with free code can be diffecult if your
> code isn't at least as good. However i am gonna wipe your ass if you
> use any part of my code or techniques unless you can swear on your
> mothers life and that of your computer that you didn't use the info i
> gave on the mail server, or the info i added too the code, or the
> code itself.
I never said that we were competing with your code. This is being developed
for a game that we will be writting for one of our clients.
As as a bonus I figured that we would release a FREEWARE version of it to
Euphorians to use. Like I said before, I haven't used your code nor do I
want to use your code. Most of the things that you have discussed I already
knew anyway or I know how to find them else where.
> " a commercial game" ??? You are gonna be rich that's for sure.....
Yep. That's the idea!
> NOT!!!! Platform games on the pc is like pacman on a Nintendo 64.
> No you need something ORIGINAL to make money.... (like Diable added
> cool multi-player options and dynamically designed levels, or like
> Lemmings, Or like Quake giving the best possible 3D graphics)
Did I mention the fact that we DIDN'T develop the Devilman demo? What part
of that statement do you not understand? And yes our commercial product
will have 3D graphics among other things like multiplayer network/modem
games.
> Your platform will not even be as good as Jazz JackRabbit, a classic
> you at least need to defeat can you call your game commercial.....
See above..
> Well, like i said, more your than mine problem!
Sounds more like your problem. We never started this flaming war in the
first place. You did.
Greg Harris
blackdog at cdc.net
Hollow Horse Software
10. Re: Fast graphics and scrolling
> Ralf Nieuwenhuijsen wrote:
>
> > Hey, i'm working on SVGA, i only need some docs and help from
> > somebody who knows assembly well and then i can write 'directly' to
> > the svga memory using that assembly to copy the stuff weird...
>
> Ralf, does this mean that your code would not be portable? Would it be
> portable with slight changes? What if, say, we wanted to create a game
> using your code and wanted PC, Mac, and Amiga people to use it...
PC is all spit-n-bailing wire, *but*:
The Amiga is *dead*, and the loss is felt, it had a *brilliant* hardware
architecture, and a really good OS.
The Mac is gonna die. I don't know enough about it, but I think many mourned it
when Jobs and Woz where kicked out. It was a brilliant concept. Simple
computers to perform simple tasks for people who aren't freaks!
Unix? It's hanging on by sheer will power. It's a real patchwork now. It was
twenty years ahead of its time. (Or Bill's, anyway) Today, twenty-five years
later (?), it's still the my recommendation.
Workstations etc.? They're all Unices.
> Course, then we have to assume, I guess, that EUPHORIA is available for
> those platforms.
For reasons listed, it probably never will be.
The moment you use *anything* other than the built-in graphics-functions,
compability goes right out the window. Sorry! (Because "anything other"
immediately means screwing with the hardware or the OS...)
> So, nevermind.
>
> Jus' wonderin',
> ck
Clark Kent? 
> P.S. You shouldn't let other people get you all riled up. Let your code
> speak for itself. It does that pretty well. :)
Yeah!
Anders
-------------------------------------------------------------------
Anders Eurenius <c96aes at cs.umu.se> ICQ UIN:1453793
Computer Science/Engineering student at the university of Umeaa
-------------------------------------------------------------------
11. Re: Fast graphics and scrolling
> Still don't you all find it cool that my code is THAT portable.
> The structure needed for animation and stuff to keep it portable was
> gotten from some tutorial that teaches you how to think right.
You're forgetting that other systems might have radically different hardware...
Your sprite-routines would be pretty rediculous on the Amiga for instance. So
even though you might be able to /run/ it, it will just crawl...
> The example program was a c-3d program, and if you change ONE
> setting it would all be protable to win95 - dos - unix - more...
All of them the same hardware... Still, pretty nifty...
> Really cool how they did it.... Duke3D is already very
> descrimination in CPU-type ... :(
> Still, i don't get 3d, for that, English is just too far from me to
> understand it well enough.
Mail me on that one!
> Ralf Nieuwenhuijsen
Anders
-------------------------------------------------------------------
Anders Eurenius <c96aes at cs.umu.se> ICQ UIN:1453793
Computer Science/Engineering student at the university of Umeaa
-------------------------------------------------------------------
12. Re: Fast graphics and scrolling
> > somebody who knows assembly well and then i can write 'directly' to
> > the svga memory using that assembly to copy the stuff weird...
> > ..........hey wait, i'm not gonna tell you this ... you don't want to
> > share your tricks too...
>
> No need to. We plan on developing a modex library next.
ModeX is cool, handy for scrolling & cutting, hey small pieces get
copied faster on the video memory than on real memory. Larger pieces
were copied slower to the video memory than to another part of
memory.
> >> This is built into the engine, no need to worry about screen boundarys.
> > Depends... do you have one big see-through screen were you
> change
> > your view offset or do you move the blocks over a 320*200 virtual
> > screen. (And thus cutting them nicely)
>
> Actually neither one I guess. We have a routine that handles clipping and
> then passes it to the display routines. It does all the out of bounds
> checking for you.
So the last one thus, your drawing is on a 320*200 screen (virtual
or not) and every thing that is placed on it is cut if needed. (that
was the last)
> > > Sorry. The source code will be shrouded when released. The registered
> > > version will be used in a commercial game we are producing.
>
> Well, I skimmed over it and found it to be less than interesting. I
> promptly deleted it from my hard drive. I always ask if I can use someone
> elses code before I use it, when at all possible. The only persons code
> that we have used is Mark Honnors (Used by permission from the author) and
> Pete Eberlein's code that he posted on the listserver.
You skimmed over a 1000+ lines file and conclude it didn't had
anything usefull, you're a fast reader then.
> I never said that we were competing with your code. This is being developed
> for a game that we will be writting for one of our clients.
> As as a bonus I figured that we would release a FREEWARE version of it to
> Euphorians to use. Like I said before, I haven't used your code nor do I
> want to use your code. Most of the things that you have discussed I already
> knew anyway or I know how to find them else where.
Sorry, your right, i was a bit argogant here.
> Did I mention the fact that we DIDN'T develop the Devilman demo? What part
> of that statement do you not understand? And yes our commercial product
> will have 3D graphics among other things like multiplayer network/modem
> games.
3D, like raycasters?
In Euphoria for Dos, we'll i'll see it then.
If you can ever make it, it will problely be about 99% asm.
And the multiplayer thing was asked by Somebody else, he wanted to
set a server or anything like that, however i also think (like Daniel
Berstein said) that you better wait for a win95 version and then call
the winsock dll.
> Sounds more like your problem. We never started this flaming war in the
> first place. You did.
Started a war?
All i heard was someone thinking they could be rich and already have
a too buzy agenda...... (that's pretty arogant)
It was that last sentence of you that had set this tone.
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
13. Re: Fast graphics and scrolling
> ModeX is cool, handy for scrolling & cutting, hey small pieces
get
> copied faster on the video memory than on real memory. Larger pieces
> were copied slower to the video memory than to another part of
> memory.
And you can get a 320 x 240 screen that actually has almost has square
looking pixels..
>You skimmed over a 1000+ lines file and conclude it didn't had
> anything usefull, you're a fast reader then.
Yep. Speed readers are us.
> Sorry, your right, i was a bit argogant here.
I was probably a bit too. The only thing I meant by "agendas" was that we
have a client that is paying us to develop code for him. I am pretty sure
that he doesn't want the source code floating around on the internet. We
maintained the technological right to it but releasing code before the
project is completed and on the market is bad for business so to speak.
> 3D, like raycasters?
> In Euphoria for Dos, we'll i'll see it then.
> If you can ever make it, it will problely be about 99% asm.
> And the multiplayer thing was asked by Somebody else, he wanted
to
> set a server or anything like that, however i also think (like Daniel
> Berstein said) that you better wait for a win95 version and then call
> the winsock dll.
I think that 3D will be available in DOS. Only the rendering part of the
raycaster will have to be assembly. As far as TCP/IP there is already DOS
ppp stack available and I have some source code to IPX routines that I
might try to convert into Euphoria.
> > Sounds more like your problem. We never started this flaming war in the
> > first place. You did.
> Started a war?
> All i heard was someone thinking they could be rich and already
have
> a too buzy agenda...... (that's pretty arogant)
> It was that last sentence of you that had set this tone.
See above. After all it did have a smily after it.. :)
Regards,
Greg Harris
blackdog at cdc.net
