DoomDragon an new level

And off cause I start an new level.

For the port Risen3D.

DoomDragon an mix between the old style of Japanese, and modern technology.:))

Screenshots

http://www.sitters-electronics.nl/Game.html



Greetings
willem

Nothing to say about this level ?

This architecture are only models !!



Greetings.

Well... without beating - I admint I have never played any of your maps (not familiar with Risen), but they always look really good. You have that... architect's taste.

Sitters makes probably some of the coolest levels out there. Too bad nobody can get them to play correctly. However, I don't put that all on his shoulders as I feel risen3d/doomsday is a dead market almost for modders and developers.

But yes, it looks really nice. Keep up the good work. If anything, I don't mind encouraging this because it could probably lead to some outstanding things if the bugs can be resolved.

Looks great! Kinda reminds of the UT2K4 map Moon Dragon - I'll assume this is inspired by it; MD is one of the few ctf maps worth playing because it has a unique mountainside feel and doesn't feel as generic as a lot of maps are - looks like this is gonna capture that same feel in Risen, can't wait.

Looking very sweet sitters. :)

Thanks everybody,

We all trying to make the best of it.
And if there are some problems we try to solve them.

Yes DeumReaper this level is inspired by the UT2K4 level.

I did like the environment from this level so much, that I was thinking, I'd going to try to make something the same for an doom level.

Greetings

sitters said:

Nothing to say about this level ?

This architecture are only models !!



Greetings.

They are? But I thought Risen 3-D had full support for 3-D geometry.

Loving the atmosphere.
May some maps look like they've been filled with models to pardon poor architecture, this one's 3d constructs blend together with basic structures to create quite a believable and atmospheric environment. Stunning work.

Nmn said:

this one's 3d constructs blend together with basic structures to create quite a believable and atmospheric environment.

I agree, it's a real strength with how models are being used in these maps.

Enjay in another thread said:

I often couldn't tell where models stopped and architechture started. It was very impressive in places.

Thanks everybody,

In Risen3D is the radius of things removed for the architecture models.

So the models can now be very big, without
the engine stop rendering.

I also used very big models by Strike Back ( making complete 3d walls ).

By very big models like the rock's in doomdragon, the skin must be the same resolution as the textures used by the basic structures, so they blend nice.

But this costs an lot of data.

Goatlord, I make my levels with doombuilder like many others do.
Risen3D support slopes and 3d floors and
fake 3d floors and that kind of stuff.
Complex 3-D geometry are models.


Willem

ooo

so when are you releasing strikeback?

BlackFish said:

ooo

so when are you releasing strikeback?

First we want to update the game-play from Genetic Disaster.

We want to use the criticize from Enjay and other people to make an better game-play.

Strike-back is an new generation levels, special make for R3D v2.00.
We don't want an level, with an nice environment and an poor game-play.

So it can take some while.

Willem

It's very pretty, but hopefully it has less of those oddly placed fake walls.

In Risen3D is the radius of things removed for the architecture models.

So how is Risen3D calculating when the models are vissible (full 3D bounding box of vertex extremes?). Then doing a 3D line-o-sight against the bounding box for each model in the current/neighbour blockmap blocks?

By very big models like the rock's in doomdragon, the skin must be the same resolution as the textures used by the basic structures, so they blend nice.

You should ask Graham to removed texture clamping on model skins. It would have no sideeffects and allow you to tile the skins like wall textures/plane flats as long as you laid the UVWs of the model out with that in mind.

DaniJ said:

So how is Risen3D calculating when the models are vissible (full 3D bounding box of vertex extremes?). Then doing a 3D line-o-sight against the bounding box for each model in the current/neighbour blockmap blocks?
You should ask Graham to removed texture clamping on model skins. It would have no sideeffects and allow you to tile the skins like wall textures/plane flats as long as you laid the UVWs of the model out with that in mind.

I ask Graham, he say:

Hi Willem,

Re: DaniJ

1) The radius of architectural models is ignored.

2) I didn't think skin textures were being clamped. I'll check this.


Greetings

1) The radius of architectural models is ignored.

That doesn't answer my question. What method are you using to determine when an architectural model is vissible?

Ignore what I wrote earlier since I've just re-read it and its garbage - You obviously wouldn't use the blockmap for that (duh)...

Wow, doom can do this? Holy crap.

DaniJ said:

What method are you using to determine when an architectural model is vissible?

It is now sector based, if you are in the sector the model is rendered, or the sector must be in the viewpoint.

Ezxariarch said:

Wow, doom can do this? Holy crap.

Thanks, And more


Greetings.

Ezxariarch said:

Wow, doom can do this? Holy crap.

No, Doom can not. That's why Sitter's using R3D.

I wish I had your skills Sitters :(, you make very original maps and your pretty good with making models.

Im kinda wondering why off all games out there, you choose classic doom to make maps/mods for.
Why not make maps for doom3, with skills like that it would be an walk in the park for you ;)

It is now sector based, if you are in the sector the model is rendered, or the sector must be in the viewpoint.

Thanks. In that case its nothing fancy like I had assumed. What MF_ flags does Risen3D check for (alongside the model DEF presence test) to flag a vissprite so that this "relaxed" visibilty check is used instead? (mobjs are normally selected by visible subsector checks using viewseg oranges)

This level looks really nice from the early screens. Good work.

dutch devil said:

I wish I had your skills Sitters :(, you make very original maps and your pretty good with making models.

Im kinda wondering why off all games out there, you choose classic doom to make maps/mods for.
Why not make maps for doom3, with skills like that it would be an walk in the park for you ;)

It is for me an challenge to come as close as possible to the modern games with the tools of the engine.

All the stuff is then made by people for free use ( except the doom2 source then ), and that is great.

DaniJ said:

Thanks. In that case its nothing fancy like I had assumed. What MF_ flags does Risen3D check for (alongside the model DEF presence test) to flag a vissprite so that this "relaxed" visibilty check is used instead? (mobjs are normally selected by visible subsector checks using viewseg oranges)

This level looks really nice from the early screens. Good work.

Only for architecture models, things from 7000-7899.


greetings
Willem

Only for architecture models, things from 7000-7899.

Ewww. Thats horrible.

If I were you I would suggest to Graham to remove this hack (sooner rather than latter before too many mods make use of this feature) and implement it PROPERLY (using new MF_ flags in a THING definition). There is no benefit AT ALL from using a "reserved" DoomEdnum range considering that you HAVE to create at least the model definition via DED anyway.

I was going to implement support for architectural models in Doomsday but there is no way I'm going to restrict it to a THING DoomEdnum range.

By doing that kind of thing Risen3D is severely damaging cross-port compatibility prospects.

For example, in Doomsday and Zdoom, one can create new THINGS using ANY DoomEdnum. I now try to load the same mod in Risen3D and Risen3D will assume that my new monster is an architecture model.

I'm not attacking Risen3D but that is a "bad" design choice.

So now, if I want to support the Risen3D method for this feature I need to create new features. I either need to determine automatically when a mod is designed for Risen3D or rely on the user to explicitly tell Doomsday.

DaniJ said:

Ewww. Thats horrible.

If I were you I would suggest to Graham to remove this hack (sooner rather than latter before too many mods make use of this feature) and implement it PROPERLY (using new MF_ flags in a THING definition). There is no benefit AT ALL from using a "reserved" DoomEdnum range considering that you HAVE to create at least the model definition via DED anyway.

I was going to implement support for architectural models in Doomsday but there is no way I'm going to restrict it to a THING DoomEdnum range.

By doing that kind of thing Risen3D is severely damaging cross-port compatibility prospects.

For example, in Doomsday and Zdoom, one can create new THINGS using ANY DoomEdnum. I now try to load the same mod in Risen3D and Risen3D will assume that my new monster is an architecture model.

I'm not attacking Risen3D but that is a "bad" design choice.

So now, if I want to support the Risen3D method for this feature I need to create new features. I either need to determine automatically when a mod is designed for Risen3D or rely on the user to explicitly tell Doomsday.

There are much more things reserved in Risen3 like for,
3D water, 3D floors , Water dynamics, linking switches and for model interaction.

So it is still not easy to make doomsday maps compatible with Risen3D, like things and 3D stuff.

But before you make architecture models in doomsday, my advice is first to pump up the speed of doomsday, and make the speed not deppend of, from how much linedefs there are.

By Risen3D it is not mather to have 3000 linedefs or 10000 lenedefs, the speed stays the same.

Doomsday cant handle my maps on this moment, I test it with Strike Back, and I have 15 FPS with doomsday and with Risen3D 100.

So my advice do something about the speed, before add an lot of features.

Greetings

So my advice do something about the speed, before add an lot of features.

Thanks for the advice but we arn't worried about speed currently.

Thing is, it is pointless optimising anything untill the implementation is completed. Since Doomsday isn't yet at the stage where everything is implemented how it should be (as far as rendering is concerned) skyjake hasn't bothered to optimise much (other than in the odd few places when necessary).

The target design for map rendering in Doomsday 1.9.1 is such that we don't recalculate the world geometry each frame unless absolutely required. This makes optimisation rather pointless considering that any profiling we do now would lead us into spending time, improving certain areas of code, when the time saved might be completely insignificant in 1.9.1 since those sections of code are no longer being called each frame.

DaniJ said:

The target design for map rendering in Doomsday 1.9.1 is such that we don't recalculate the world geometry each frame unless absolutely required. This makes optimisation rather pointless considering that any profiling we do now would lead us into spending time, improving certain areas of code, when the time saved might be completely insignificant in 1.9.1 since those sections of code are no longer being called each frame.

I agree,

Greetings.

And some new shots from DoomDragon.:)


http://www.sitters-electronics.nl/Game.html

Greetings.

I love that cave with the glowing crystals.

Very "Unrealish".