Page 1 of 1

Current Feature Suggestions

PostPosted: Fri May 27, 2005 9:59 am
by QBasicer
What are the current feature suggestions? Reply with their categorization and priority, as follows.

Engine:
- True 3D (LOW)
- 32 Bit (LOW)

UI/Bugfix
- Some error Enjay is going on about in the status bar (HIGH)


I'll see if I can keep editing this post as more suggestions come.

Categories:
- Engine (Rendering type stuff)
- Texturizer
- Gameplay
- Netcode (Multiplayer)
- Players
- Monsters
- Lighting
- Game Compatibility
- Bugfixes
- UI
- Other (Demos, etc)

I think that'll do for now, don't you?

Current List:
    Polymost (N/A) Nmn
    Build-style handling of sprites (N/A) Nmn
    ACS_changeplayerskin (N/A) Nmn
    Custom decorate weapons (N/A) Nmn
    Real 3D structures (N/A) Graf-Zahl
    Strife dialog support (N/A) Graf-Zahl
    Inventory support (N/A) Graf-Zahl
    More code pointer (N/A) Graf-Zahl

PostPosted: Fri May 27, 2005 1:15 pm
by Nmn
I just want Polymost and Build-style handling of sprites. With flat sprites, a mapper could fake 3dness with great ease.

And ACS_changeplayerskin would also be of great use.

And custom decorate weapons full support. I don't care about anything else :)

PostPosted: Fri May 27, 2005 1:22 pm
by Graf Zahl
Nmn wrote:I just want Polymost and Build-style handling of sprites. With flat sprites, a mapper could fake 3dness with great ease.


If we get there why not go the whole step and do real 3D structures. If you can solve one the other isn't much of a problem anymore. I'd rather not see yet another hack introduced.

And custom decorate weapons full support. I don't care about anything else :)


And Strife dialog support, inventory support, more code pointers etc. It's all there and just waiting...

PostPosted: Sun May 29, 2005 7:16 pm
by QBasicer
Updated.

PostPosted: Thu Jun 02, 2005 2:27 pm
by Nmn
Graf Zahl wrote:
Nmn wrote:I just want Polymost and Build-style handling of sprites. With flat sprites, a mapper could fake 3dness with great ease.


If we get there why not go the whole step and do real 3D structures. If you can solve one the other isn't much of a problem anymore. I'd rather not see yet another hack introduced.

AFAIK that would be hard because of the Zdoom renderer. I'm aiming at thigns that wouldn't cause trouble with implementation, like rewriting something from scratch. Correct me if I'm wrong here about the renderer :?

And custom decorate weapons full support. I don't care about anything else :)


And Strife dialog support, inventory support, more code pointers etc. It's all there and just waiting...

Actually, given the current moment and my abilities I only care about Decorate weapons. Dialogs with multiple choices and inventory could be done via ACS.

PostPosted: Thu Jun 02, 2005 7:20 pm
by QBasicer
I, however I know this won't happen, would like to see somebody bite the bullet and recode the engine.

PostPosted: Fri Jun 03, 2005 3:02 am
by Graf Zahl
Nmn wrote:
Graf Zahl wrote:
Nmn wrote:I just want Polymost and Build-style handling of sprites. With flat sprites, a mapper could fake 3dness with great ease.


If we get there why not go the whole step and do real 3D structures. If you can solve one the other isn't much of a problem anymore. I'd rather not see yet another hack introduced.

AFAIK that would be hard because of the Zdoom renderer. I'm aiming at thigns that wouldn't cause trouble with implementation, like rewriting something from scratch. Correct me if I'm wrong here about the renderer :?


Both require z-clipping. If you can render one polygon you can also render another polygon and if you enforce GL nodes for 3D-floors that's exactly to what they are reduced.

And custom decorate weapons full support. I don't care about anything else :)


And Strife dialog support, inventory support, more code pointers etc. It's all there and just waiting...

Actually, given the current moment and my abilities I only care about Decorate weapons. Dialogs with multiple choices and inventory could be done via ACS.

[/quote]

No need to bother. All the code already exists.

PostPosted: Fri Jun 03, 2005 7:08 am
by Nmn
Graf wrote:Both require z-clipping. If you can render one polygon you can also render another polygon and if you enforce GL nodes for 3D-floors that's exactly to what they are reduced.

So You support the idea of having polygons in Zdoom? (EDIT: Upon writing I remembered the flats are already treated as polygons, so please keep in mind my low rendering code knowledge ATM)

Graf wrote:No need to bother. All the code already exists.

That's right, but I'd rather have it in an official release tough. Anyway, that's half-success.

PostPosted: Fri Jun 03, 2005 7:26 am
by Graf Zahl
Nmn wrote:
Graf wrote:Both require z-clipping. If you can render one polygon you can also render another polygon and if you enforce GL nodes for 3D-floors that's exactly to what they are reduced.

So You support the idea of having polygons in Zdoom? (EDIT: Upon writing I remembered the flats are already treated as polygons, so please keep in mind my low rendering code knowledge ATM)


Don't be confused by the term 'polygon'. The important thing is the clipping involved. And for flat sprites it's mostly the same as for a real polygon.

Graf wrote:No need to bother. All the code already exists.

That's right, but I'd rather have it in an official release tough. Anyway, that's half-success.


Me, too!

PostPosted: Fri Jun 03, 2005 7:33 am
by Ajapted
Nmn wrote:So You support the idea of having polygons in Zdoom? (EDIT: Upon writing I remembered the flats are already treated as polygons, so please keep in mind my low rendering code knowledge ATM).

The main issue when adding 3D floors to a software renderer is drawing everything in the correct order. To make it glitch-free is probably not possible without significantly changing the way the renderer works, and when you do that (like we did for EDGE) then some of the old map tricks stop working (or become difficult to emulate).

Adding 3D floors to an OpenGL or Direct3D port (like Risen3D did) is easier since you can rely on the depth-buffer (what I assume Graf means by "z-clipping") without needing to get the order right (but if you want translucent stuff then you still need to get the order right).