Page 1 of 2
[2.1.5] Bug : Jumpy slope textures
Posted: Mon Sep 25, 2006 2:31 pm
by Espi
http://koti.phnet.fi/repoes/jumpytex.wad
When you turn around slowly, you can see that the textures on the ceiling shift a bit. This seems to happen when the sector's sloped and its texture is aligned to a line. The effect is more noticeable in a level I'm working on.
Posted: Mon Sep 25, 2006 3:08 pm
by Graf Zahl
Ugh. That doesn't look good at all...
Posted: Tue Sep 26, 2006 8:49 am
by randi
I wish I had saved the page where I learned the math for this. Now I can't even find it with Google, and I've forgotten what it's doing.
At least this is nowhere near as bad as what I saw on Blood's BB3 in an old version, where a slope's texture changed orientation dramatically based on how you looked at it.
Posted: Sun Oct 01, 2006 12:11 pm
by Espi
... Does that mean it won't be fixed?
It's quite strange really. I can copy a structure from my map to a new map, and it looks solid and all. When the exact same structure is in my map however, the textures go nuts. x_x In addition to jumping around, it looks like the texture is shifted "outwards" from the slope by a few pixels, if that makes sense.
Posted: Sun Oct 01, 2006 9:03 pm
by randi
I'd like to fix it. Maybe when I do certain other currently secret things to the renderer I can deal with it. (And no, I don't mean OpenGL, although I still want to do that at some point too.)
Posted: Mon Oct 02, 2006 2:44 am
by Nash
Secret things? Let me guess: flat decals support, software-based 3-d floors, real-time scalable and rotatable textures and sprites, moving sectors or... *gosh* Polymost!
(okay that's not a guess, that's a wish list. >=))
Posted: Mon Oct 02, 2006 2:53 am
by Graf Zahl
I'd rather see DoomScript or a floating point engine.
Posted: Mon Oct 02, 2006 7:59 am
by HotWax
Graf Zahl wrote:I'd rather see DoomScript or a floating point engine.
My prediction for the 2.1.7 changelog:
Code: Select all
- Finally, DoomScript is now part of ZDoom! DoomScript is a package of various tools and addons to ZDoom that together make up a complete and powerful method to create an unlimited amount of custom content. DoomScript is made up of the following items:
- ACS (Including the LOADACS lump)
- DECORATE
- DEHACKED
- MAPINFO
Now you can stop bugging me for DoomScript!!! =)
Posted: Mon Oct 02, 2006 8:16 am
by Graf Zahl
If that happens I'll familiarize myself with parser generation and do my own thing. Of course due to my limited knowledge that most likely won't be as good as it should be.
Posted: Mon Oct 02, 2006 8:44 am
by HotWax
I kid, I kid.
Posted: Mon Oct 02, 2006 9:52 am
by Graf Zahl
Posted: Mon Oct 02, 2006 10:47 am
by Nash
Knowing Randy's schedule, this won't happen until 2005
You were wrong by one year.
Posted: Mon Oct 02, 2006 10:51 am
by Bio Hazard
I don't think DoomScript can be done easily and effectively with all the other crap iun the engine. I'd fork it off to another branch for development. That way you won't back-up the flow of releases while you are writing that monster.
** EDIT: Here comes another one of those rants I make every time I read about the future of ZDoom, sorry. ***
I'd still go through the code and eliminate all the backward-compatible crap, but nobody wants to do it in fear of breaking some jokewad that nobody really cares about. I say if a great wad gets broken, people will fix it. Look at ZDCMP for an example. .90 broke it and the community rose up and fixed it. Why wouldn't that happen for other wads? I'm sure if a wad is good enough, the community would fix it.
Would it reall be that difficult to branch ZDoom and make a clean engine out of it? SVN makes managing paralell projects very simple. It could have the newest features and be free of backwards compatibility code slowing it down. Graf could put in his GL renderer, the cross-platform could be less hacky, the actors could be moved out of the EXE (via DoomScript), the sound engine could be updated, ACS could get totally rewritten to make it more useful (or just ditch it completly for DS), the filesystem could be totally switched to path-based PK3, the map format could be extended, the code could be tweaked for speed and many other advantages that would just make the current ZDoom
huge. If it was branched, you could still keep
the old ZDoom in development for the backwards compatibility. Again, SVN would make this very easy.
Go read the docs on branching.
Gah, I'm ranting about the future of ZDoom again, who am I kidding? You guys don't want to make ZDoom cleaner. Sorry for wasting your time again, it just really bothers me that you go out of your way to support dirty hacks that
we all agree are dirty hacks...
Posted: Mon Oct 02, 2006 10:58 am
by Nash
Yeah, ZDoom editing revolves a lot around hacks. A lot of great things you see people doing in ZDoom are accomplished by exploiting this feature, or using that feature in a way it was not meant to be used, etc.
But I still love it... I mean, it's tons easier to edit than, say, Doom 3.
Posted: Mon Oct 02, 2006 11:38 am
by Graf Zahl
Bio Hazard wrote:I don't think DoomScript can be done easily and effectively with all the other crap iun the engine. I'd fork it off to another branch for development. That way you won't back-up the flow of releases while you are writing that monster.
** EDIT: Here comes another one of those rants I make every time I read about the future of ZDoom, sorry. ***
I'd still go through the code and eliminate all the backward-compatible crap, but nobody wants to do it in fear of breaking some jokewad that nobody really cares about. I say if a great wad gets broken, people will fix it. Look at ZDCMP for an example. .90 broke it and the community rose up and fixed it. Why wouldn't that happen for other wads? I'm sure if a wad is good enough, the community would fix it.
no, No, NO!!!
Backwards compatibility is important. Imagine a Doom port which has constant problems playing vanilla maps. It'd get a massive beating from the community - and a very bad reputation. Wait a minute: such a port already exists and it's called Vavoom...
Would it reall be that difficult to branch ZDoom and make a clean engine out of it? SVN makes managing paralell projects very simple. It could have the newest features and be free of backwards compatibility code slowing it down. Graf could put in his GL renderer, the cross-platform could be less hacky, the actors could be moved out of the EXE (via DoomScript), the sound engine could be updated, ACS could get totally rewritten to make it more useful (or just ditch it completly for DS), the filesystem could be totally switched to path-based PK3, the map format could be extended, the code could be tweaked for speed and many other advantages that would just make the current ZDoom
huge. If it was branched, you could still keep
the old ZDoom in development for the backwards compatibility. Again, SVN would make this very easy.
Go read the docs on branching.
1. The moment ZDoom is no longer compatible enough with vanilla maps I'll quit. Period. Such a project is not worth developing for IMO.
2. Same for ditching ACS and other stuff that's been used in many, many maps.
3. Any engine that is not backwards compatible is no engine at all (ok, I'm repeating myself)
4. Guess why I re-introduced the sector-based soundtarget code for 2.1.0. The actor based replacement just broke far too many WADs and these were issues that are not easily fixed.
Gah, I'm ranting about the future of ZDoom again, who am I kidding? You guys don't want to make ZDoom cleaner. Sorry for wasting your time again, it just really bothers me that you go out of your way to support dirty hacks that we all agree are dirty hacks...
Ranting indeed. Making what you suggest would destroy ZDoom, not save it and therefore it won't happen.
If DoomScript is implemented it will be an extension to DECORATE and in no way interfere with the compatibility code you so despise.