AnimTextures SUCK!!!
Blitz3D Forums/Blitz3D Programming/AnimTextures SUCK!!!
| ||
| The current AnimTextures system is terrible. It should be automatically updated, with an AnimTextureSpeed() command. I was going to add these to the material editor, but quit, because the built-in commands are pretty much useless. There's not even a command to retrieve how many frames an animtexture holds. |
| ||
| wherefrom shall the command know if a "black tex" is no wanted frame? this is a pc not a human ;) the thing with anim speed would be really a nice addition if updated with renderworld or capture world automatically like other animations too |
| ||
| Actually I think it would be really useful if the animTexture framerate does not wait for UpdateWorld or anything and instead loops at a set frames per second rate. Sort of like how movie playback works; the movie just plays at a certain speed in the background, and the frame displayed whever you call DrawMovie is whatever frame the background playback happens to be at. |
| ||
| Yeah, that's what I meant. |
| ||
| It offers all you need, you can wrap a shell around it that does all that in 5 minutes. Oh well, guess you just don't like having to do things yourself occasionaly. :P |
| ||
| "I was going to add these to the material editor, but quit, because the built-in commands are pretty much useless." That's funny... My Anibrush system animates the texture and all other properties of a brush. I certainly don't see any problem with the texture animation commands. They work just fine. The only thing I'd wish for was for Mark to implement all my Anibrush system commands into Blitz so that every brush could be either a regular brush or an Anibrush and be automatically updated. The reason for this is that as it is now, my Anibrush system can't be used without writing special versions of commands that accept a brush parameter, because an anibrush is a type. And I beleive you folks have overlooked the fact that someone might want to pause their game once in a while, at which point you would not want the textures to continue animating. Also you would still need manual control over the animation speed for all sorts of things. |
| ||
| I agree. However, having a type of frames, speed and maxframe isn't really that much of a drag. Then you just have a function that runs through the type doing something like type frame# speed# maxframe endtype for each frame = int ((frame + speed) mod maxframe) next |
| ||
| I'm not overlooking that other stuff. When I suggested this stuff once a while ago (not as vehemently as halo of course) I suggested an optional framerate parameter (lots of commands have optional parameters) to make the animated texture automatically loop at a set framerate. Then if you don't set that optional parameter AnimTextures would just work exactly as they do now. As for pausing, I suppose there would have to be a StopAnimTexture command. In fact, maybe doing things that way would be best. Instead of a framerate parameter when loading the texture in the first place, there are commands for PlayAnimTexture(texture,framerate) and StopAnimTexture(texture) |
| ||
| It offers all you need, you can wrap a shell around it that does all that in 5 minutes. Oh well, guess you just don't like having to do things yourself occasionaly. :P That's the point. Why are we having to write wrappers? If you're going to implement an animated texture system, make it useful. The existing one is basically worthless. I considered using it in my latest game and opted to write my own. It's just that bad. |
| ||
| The point is for it to work on it's own. You shouldn't have to wrap every existing Blitz object in your own structures. As it is, you have to write a wrapper for every Blitz command just to make use of the thing. I think that's really the core of this recent "Why aren't people making games" debate. You have to write a whole additional layer of structures just to track everything, and by that time, no one's code is compatible with anyone else's anymore. |
| ||
| I agree with the original post. |
| ||
| That is a good point I can't recall a single blitz made project of mine which hasn't had to make use of custom sound libs/entity management etc all based on blitz. But I'm guessing the reason for this is allow us to branch off in whatever direction we want to take it, rather than being stuck with one man's vison of how a sub-system should be. We don't want to end up with a unreal like ide where everygame looks and feels the same without major modifcations. That is the cost of simplicity... |
| ||
| @octagon: dunno -- there are some basics that are common to any game -- thats what I'm going through right now -- picking out the pieces and designing the framework. The "look" is all in the artwork, the "feel" is all in designing the style of play -- an IDE-like core + runtime library that lets you pull all the pieces together and easily manage them doesnt have to limit what you do with the resources. Want me to start a new thread to ask what y'all would like to see in an artwork management/game creation IDE ?? I've got some ideas in mind and would like some additional input. |
| ||
| I never understood why mesh animations can be automatically handled within UpdateWorld but not textures. I always thought that there should be something similar to handle animated textures in a similar way - it just seems intuitative to me. |
| ||
| Go for zom...can't speak for the others but I'm always interested in anything that goes even just a little way to making coding less of a effort. (Your key audience is the lazy git. We are many..and we are lazy. ;) ) |
| ||
| We don't want to end up with a unreal like ide where everygame looks and feels the same without major modifcations. That is the cost of simplicity... No, that's the cost of a poor coding/art team. Unreal Tournament 2004, Splinter Cell, Thief 3 ... these games look and feel identical? Of course not. They had competent teams behind them... |
| ||
| Splinter Cell used the UNREAL engine? Was that shadow technology built in, or did they add it themselves? Also, does Epic have one engine caleld the Unreal engine, or do they have an Unreal engine, and an Unreal Warfare engine? Or is it just called the Unreal Warfafe engine now? |
| ||
| @otacon: Ok.. gonna start it up in the Other Tools forum. |
| ||
| Unreal Tournament 2004, Splinter Cell, Thief 3 ... these games look and feel identical? Of course not. They had competent teams behind them.. Hey I love the splinter cell games, I'm no argueing that. Though I'd say thief is pushing it tech wise, as I've heard some truely awful tales of how buggy/slow a job ion did.(To the point of where 25 people including the heads of thief 3 and deus ex 2(Randy and hervey smith!) resigned/fired.) My point is to do that, because unreal is so specialized towards one genre, it was a lot of work. For instance cameras needing set up via ini files. (the camera work suffers as result imo. Compare it to the masterfully cinematic mgs2's camera work) it just makes it that much harder to branch off in another direction that wasn't in the mind of the original engine makers. imo. |
| ||
| It's not though. People tend to make first person shooters, but the engine is general enough that they could do whatever they want. Move the camera upwards and look down ... hey, an RTS! Digital Extremes did this with the original Unreal Tournament engine ... they changed a few things with the camera and made a cool pinball game. |
   |