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.
|
Not Categorized, Please Help
|
|
