1. 3D Graphics
Hello Talvitie, Glen, others...
>cause you don't really need the engine source and all you want is bitmap(?)
>files, why not use some executable ray tracer to do the job. You can
>propably download one from the web.
Well, actually, I DO need an engine to call from my
program. I don't just want bmp files because:
1. That's a lot of extra size to distribute
2. It limits the player to a certain sprite set
What I want to do is allow the player when creating
a character, choose:
Race -- Human, Elf, Dwarf
Sex -- Male, Female
both of which will affect the way the character looks
on the screen. The way I figured it, I need about 2400
sprites per character (assuming race and sex don't change)
If I just included sprites for every combination that
a player might choose in the distribution then that makes
it 14,400 sprites. I don't want to do that! Hopefully,
you can see now why I need the sprites to be created when
a character is created.
I might look at POV-ray anyway because it sounds interesting.
later,
Lewis Townsend
PS. Glen, I'll keep you in mind if I need any graphics that
won't be generated in game.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
2. Re: 3D Graphics
On Mon, 27 Sep 1999 16:06:51 GMT, Lewis Townsend <keroltarr at HOTMAIL.COM>
wrote:
>2. It limits the player to a certain sprite set
>What I want to do is allow the player when creating
>a character, choose:
>Race -- Human, Elf, Dwarf
>Sex -- Male, Female
>both of which will affect the way the character looks
>on the screen. The way I figured it, I need about 2400
>sprites per character (assuming race and sex don't change)
Lewis Townsend
Lewis
Why couldn't you just build the sprite as your user selects it.
Different hair styles, faces, body sizes, hats and etc would be pieced
together from the various parts and place in that user's game sprite
It seems that this would limit the number of sprites and give you
lots of variations of characters.
Bernie
3. Re: 3D Graphics
Hello Bernie,
>Lewis
>
> Why couldn't you just build the sprite as your user selects it.
>Different hair styles, faces, body sizes, hats and etc would be pieced
>together from the various parts and place in that user's game sprite
Yes, in escence, this is what I'm talking about. I won't
be concern with small things such as hair color and
facial features but body-size and hats (helmets), I will.
> It seems that this would limit the number of sprites and give you lots
>of variations of characters.
>
>Bernie
It would except for the fact that a character can change
clothes (armor) and weapons at any time in the game. What's
more, there is 8 directions a character can move and attack
in. 3 walking positions, 3 attacking positions, 3 armor
types, and 7 weapon types. I also factor in if a character
is wearing a helmet or bearing a shield. If I only show the
weapon when the character is attacking I can limit the
sprite-set to 2304 sprites per character but no less. I can
provide you with the function I use to calculate all this
with if you want.
I hope I've explained it better this time,
Lewis Towsnend
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
4. Re: 3D Graphics
Bernie, and others
Robert Pilkington just wrote me and suggested that I misunderstood you about
your suggestion for the 3D looking sprites:
Robert wrote:
>PS. On the Listserver, I think Bernie was referring to having each
>component
> prerendered. Then, compile them all together in memory when ready.
>
>Ie, take Armor1.bmp, Sword3.bmp, and M_Elf.bmp, and put them into memory.
>Then, combine the frames (ie all 1st frames with 1st frames, 2nd
>frame of each file with the second frame of every other file) into a new
>.bmp sequence in memory. If the player changes armor, then recompile the
>sprites
>in memory again with the new settings. It should be very fast, I'd think.
If this is what you meant, my appologies for
misunderstanding. I hadn't thought to do it this way.
It might be a very good idea. It would take less actual
sprites for a character and I could let them carry their
weapon around with them without penalty.
In which case: I might just do all the rendering with that
POV ray program someone suggested.
thanks,
Lewis Townsend
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
5. Re: 3D Graphics
- Posted by Talvitie <smtoa at SAUNALAHTI.FI>
Sep 27, 1999
-
Last edited Sep 28, 1999
Lewis wrote:
>All I need is for sure:
>
> - Flat shading
> - Textured faces (with perspective correction)
> - Linked objects with individual rotations
> - Limited viewing area to make small sprites
> - Fast enough to to create about 2500 sprites in 1 min.
> - Shiny (reflective) surfaces.
Are you in hurry to get the engine? I'm not far away to from what =
you ask, but my only problem is that I have so little time(being busy as =
always).
You haven't told what kind of game your doing. Is it a beat 'em up?
Howcome you need 2500 sprites/minute? =3D ~41spr/s ...so if the game =
runs with somewhat 21fps, as I assume, then there's only two sprites att =
the same time on the screen, right?
In that case, it would be very fast to generate the sprites in real =
time. You have no idea how optimized engine I could build for that ;)
> - Shiny (reflective) surfaces.
ooops...this would need ray tracing. veeery slow! (well, I'm working =
with this new idea o' mine but can't promise any speed for that eighter =
(yet ;)
Lewis also wrote:
>Wait, if a graphics library clips pixels that are off
>the screen... Is that going to be slower than a program
>that performs checks and only draws pixels to the right
>locations using an "fast" library? How is clipping any
>slower than those pre-draw checks? They both do basically
>the same thing, right? Why the speed difference?
As you know, I'm working with 3D engine and it has to do the clipping =
one way or another.
way 1: using 3D clipping: very fast
way 2: (what I'm currently using) using 2D clipping. Basicly the same =
what you wrote (if pixel over the edge then don't draw it), but if my =
engine does the clipping instead of graphics library, I can 1. clip of a =
sequences of pixels instead of clipping 'em one by one(which is slow) =
and 2. not to calculate every pixel's color values and distance, and 3. =
avoid the error that occurs when trying to access the Buffers in wrong =
places(you can't f.ex. run this line without an error: sequence s =
s=3Drepeat(1..3) if s[-1] or s[4] then end if see?!)
way3: Let the library do the work. Won't work, as I explained in the way =
2.
anywayz...
Tell me more about your game project. It seems to me that you really =
should use an 3D engine and maybe in real-time?! This could provide very =
smooth, cool and fast way. Well, ofcourse using sprites is always faster =
and Bernie's suggestion wasn't bad eighter, I think. After all, when =
coding a game man always have to do some compromises...
and, if you really want to build the srites, it won't take as much as =
minute with my (or with any other's?) engine. If player has to wait =
minute every time he/she f.ex. starts a new level... eh? Isn't that a =
bit too much?
--Talvitie
6. Re: 3D Graphics
On Mon, 27 Sep 1999 19:43:39 GMT, Lewis Townsend <keroltarr at HOTMAIL.COM>
wrote:
>Bernie, and others
>
>Robert Pilkington just wrote me and suggested that I misunderstood you
about
>your suggestion for the 3D looking sprites:
>If this is what you meant, my appologies for
>misunderstanding. I hadn't thought to do it this way.
>It might be a very good idea. It would take less actual
>sprites for a character and I could let them carry their
>weapon around with them without penalty.
>
>In which case: I might just do all the rendering with that
>POV ray program someone suggested.
Lewis
That is exactly what I was trying to suggest
Bernie
7. Re: 3D Graphics
Hello Talvitie,
> Are you in hurry to get the engine? I'm not far away to from what you
>ask, but my only problem is that I have so little time(being busy as
>always).
I can empathize.
>You haven't told what kind of game your doing. Is it a beat 'em up? Howcome
>you need 2500 sprites/minute? = ~41spr/s ...so if the game runs with
>somewhat 21fps, as I assume, then there's only two sprites att the same
>time on the screen, right?
Heh heh, I think there might be a slight misunderstanding
here. What I meant by 2500 sprites in one minute was that
when ever a character is created the game generates about
2500 (2304 to be exact) sprites and I wanted it to be fast
enough to do it all in no more than one minute. This would
only occur once for each character, not continously
throughout the game.
The game is to be a realtime RPG (role playing game). Sort
of midieval-like with swords, shields, and armor etc...
If I could keep those 2304 sprites in memory at all times
then I could just blit them to the screen faster than any
3D engine could create them. There will be many sprites on
the screen at a time but very few (maybe only one) would be
of the kind that requires 2304 sprites in memory.
>In that case, it would be very fast to generate the sprites in real time.
>You have no idea how optimized engine I could build for that ;)
Well, I'll have to look at it when you get it finished. If it
IS really fast then maybe I could make a BETTER game with LESS
WORK just using the 3D engine instead of sprites.
> > - Shiny (reflective) surfaces.
>ooops...this would need ray tracing. veeery slow! (well, I'm working with
>this new idea o' mine but can't promise any speed for that eighter (yet ;)
Well, it wouldn't HAVE to have reflecive surfaces if I created
the textures with a raytracer (like POV-ray) things could sort
of LOOK shiny even if they weren't really.
>Lewis also wrote:
> >Wait, if a graphics library clips pixels that are off
> >the screen... Is that going to be slower than a program
> >that performs checks and only draws pixels to the right
> >locations using an "fast" library? How is clipping any
> >slower than those pre-draw checks? They both do basically
> >the same thing, right? Why the speed difference?
>
>As you know, I'm working with 3D engine and it has to do the clipping one
>way or another.
way 1: using 3D clipping: very fast
>way 2: (what I'm currently using) using 2D clipping. Basicly the same what
>you wrote (if pixel over the edge then don't draw it), but if my engine
>does the clipping instead of graphics library, I can 1. clip of a sequences
>of pixels instead of clipping 'em one by one(which is slow) and 2. not to
>calculate every pixel's color values and distance, and 3. avoid the error
>that occurs when trying to access the Buffers in wrong places(you can't
>f.ex. run this line without an error: sequence s s=repeat(1..3) if s[-1]
>or s[4] then end if see?!)
>way3: Let the library do the work. Won't work, as I explained in the way 2.
Okay, that makes sense. I don't suppose it would have much
effect on a game like mine anyway since all the 3D stuff would
be small objects.
>
>anywayz...
>Tell me more about your game project. It seems to me that you really should
>use an 3D engine and maybe in real-time?! This could provide very smooth,
>cool and fast way. Well, of course using sprites is always faster and
>Bernie's suggestion wasn't bad eighter, I think. After all, when coding a
>game man always have to do some compromises...
No kidding. I'm trying to find the best BALANCE of looks and
performance. I'll probably end up testing each possibility
before I choose which I like best.
>and, if you really want to build the srites, it won't take as much as
>minute with my (or with any other's?) engine. If player has to wait minute
>every time he/she f.ex. starts a new level... eh? Isn't that a bit too
>much?
Not for every LEVEL, for every CHARACTER. And if it takes too
long, that's only going to be once per game.
Well I hope I answered some of your questions
later,
Lewis Townsend
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
8. Re: 3D Graphics
- Posted by Talvitie <smtoa at SAUNALAHTI.FI>
Sep 29, 1999
-
Last edited Sep 30, 1999
Hello Lewis.
I hadn't read your message when I posted my last one. So... I agree =
100% with Bernie...use POV-Ray to generate sprites and then combine 'em =
in the game. You propably get best graphics this way and the game will =
be very fast. I might say that in your case, don't even consider using =
3D engine! =20
btw, I have used this sprite combine method in one of my QBasic games. =
Ok, the graphics were grap, but it saved a lot of time and memory when I =
had separate images for legs and another ones for the upper body.
Your game project sound very interesting for me. Can't wait to see it!
--Talvitie
9. Re: 3D Graphics
- Posted by Talvitie <smtoa at SAUNALAHTI.FI>
Sep 29, 1999
-
Last edited Sep 30, 1999
Hello Lewis.
I hadn't read your message when I posted my last one. So... I agree =
100% with Bernie...use POV-Ray to generate sprites and then combine 'em =
in the game. You propably get best graphics this way and the game will =
be very fast. I might say that in your case, don't even consider using =
3D engine! =20
btw, I have used this sprite combine method in one of my QBasic games. =
Ok, the graphics were grap, but it saved a lot of time and memory when I =
had separate images for legs and another ones for the upper body.
Your game project sound very interesting for me. Can't wait to see it!
later,
--Talvitie
