• Advertisement

Archived

This topic is now archived and is closed to further replies.

i have only two ideas on how to scroll my terrain..,

This topic is 5525 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi, it''s lock/unlock the VB, or rendering the terrain twice, moving them using world transformation.., ehm any other ideas? thanks,

Share this post


Link to post
Share on other sites
Advertisement
oh okey sorry,

i''m making a 3d top down space shooter, so moving the camera is a no-no,

Share this post


Link to post
Share on other sites
but if i use a world matrix then i''d have to render the terrain twice now...,

Share this post


Link to post
Share on other sites
quote:
i''m making a 3d top down space shooter, so moving the camera is a no-no,


WHY?

You think in a box - and this is not good. Name me sensible reasons why moving the camera is not possible.


Regards

Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)

Share this post


Link to post
Share on other sites
hey guys,

i''m sorry for the lack of details(probably am not good at explaining stuffs), anyway

thona:
if i move the camera instead, then i''ll have two SetTransform(D3DTS_VIEW...) now in my code right? is this what you''re letting me think? first camera is for the terrain while the second camera is for the player and all other objects,

CGameProgrammer:
if i move only one terrain, then the terrain(or player/screen) would eventually reach the end of the terrain, then i''d would suddenly ''jump'' the terrain back to it''s original position and start scrolling it again?

but if it''s two terrains, then i''d render the second on ''top'' of the other then i''d scroll them at the same time, this way, if the first terrain reaches it''s limit then i can ''jump'' it on the second''s terrain start position and start scrolling again from there, and same goes with the second terrain over and over again,

Share this post


Link to post
Share on other sites
Since its in a ''top-down'' perspective, why not pre-render the level and create a ''Big Bitmap Tile Engine'' out of it? I don''t see the need for rendering the terrain real-time if its top-down with a fixed perspective, it would save you some major FPS and also enable you to display only the tiles needed at any given point in the level

''Chris

Share this post


Link to post
Share on other sites
Mickey, if you must do 3D terrain (in other words, if the tile engine approach will not work for you), then I have a couple of points to mention:

(1) You only need one camera and one SetTransform() call for the view matrix. Just keep the terrain in a fixed location and move the camera (the view matrix) with a single SetTransform() call.

(2) If you follow step (1), then, yes, you will have the problem of what to do when the camera reaches the edge of the terrain (which you mentioned). Solve this problem by keeping several smaller "patches" of terrain that you rotate like a conveyer belt. When one patch goes offscreen, rotate it around to the front of the line. I do this in my own game, and it works well.

Okay, so how do you achieve this patch rotation? Well, either you can keep a dynamic vertex buffer and update the positions of a patch's vertices each time it gets rotated (rendering all patches with a single DrawIndexedPrimitive() call), or you can use a static buffer, assign each patch its own world matrix and render the patches with separate DrawIndexedPrimitive() calls.

I can't say which approach would work better for you because I don't know the details of your game.

Hope this helps.
--Hoozit (who likes parentheses).

(edits: clarity)
----------------------
Check out my game demo and resume at
www.fivestory.com/projects/game.

[edited by - HoozitWhatzit on December 4, 2002 4:48:49 PM]

[edited by - HoozitWhatzit on December 4, 2002 4:49:53 PM]

Share this post


Link to post
Share on other sites
well, it's not really sort of fixed perspective, i'm planning to have 3 different views, each with a slight tilt since the game is already 3d i might as well take advantage of it,

HoozitWhatZit: hiya, do you mean by patches is, the last few lines/parts of the terrain's bottom vertices? then transfer it to the front right?

i don't understand why you guys keep on pushing 'moving the camera instead', if i move the camera, everything would scroll! even the player's ship and other objects which shouldn't be scrolling, unless like i said, my terrain has it's own camera and my other objecvts another one,

is this what thona is suggesting?

i don't know if posting this
screenshot would help, anyway, that's what i want to scroll, the 'terrain',

thanks guys for trying to help me out,


[edited by - mickey on December 4, 2002 10:52:34 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The ship won''t scroll if you move it with the camera Moving the camera doesn''t mean just moving the camera without the objects. You''ve gotta move your ship and your camera at the same time.

Share this post


Link to post
Share on other sites
I think you should scroll the ship ONLY, the camera could follow
the ship then...

Kamikaze

Share this post


Link to post
Share on other sites
Mickey,

No, actually, I meant a patch to be a rectangular section of floor terrain, m vertices wide by n vertices tall. Rotate this entire section from back to front. Judging by your screenshot, you probably want infinite terrain to keep appearing in front of the player ship, right?

I agree with everyone about the camera. It''ll be the easiest situation for you if you just have the camera track the player ship''s movement. That way, you won''t have to update the enemy ships'' world matrices to account for the player''s movement.

Which sounds easiest to you: updating one matrix per frame or updating 10?

--Hoozit.

----------------------
Check out my game demo and resume at
www.fivestory.com/projects/game.

Share this post


Link to post
Share on other sites
There is actually no reason not to have the player move forward, too :-)

With just the 8 decimals you get as precision from a float you can encode, you get an awfull large space :-)

Regards

Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)

Share this post


Link to post
Share on other sites

  • Advertisement