Home » SIRTECH CLASSICS » Jagged Alliance: Unfinished Business » Tools and Guides Repository (Archive) » Improving Original JA2 graphics
|
|
Re: Improving Original JA2 graphics [message #179438]
|
Sat, 29 March 2008 14:34
|
|
BirdFlu |
|
Messages:438
Registered:September 2007 Location: Lampukistan |
|
|
I. PNGs
I think the main problem with png images will be the blitting. If i have seen it correctly,
then almost every blitting function works on 'ETRLEObject's (these are the compressed .STI
subimages). That is you cannot just push an arbitrary block of data (unpacked image data) into
the function and expect it to work. You would either have to convert pngs into ETRLEObjects
(not really an option) or you would have to change the blitting functions, which should not be
thaaaaaaaat big of a problem, as the STI/ETRLE compression is by all means trivial. The actual
problem is the inline assembler code.
Another point is transparency. Can someone give me a specific example of what you would do with
a 50% transparent image. I could think of some examples myself, but just want to know what others
are expecting.
II. 2D vs. 3D
There is this discussion about a 3D engine and as I see it, there were mostly requests for an
engine and there was almost noone who actually knows how a 3D engine works or how Vertex processing or
Fragment processing works or how GPU shaders work (I may be wrong in that point). This knowledge
would be really helpful to program an engine or even to use it, as it might help to find where
the problem lies, if something is not going as expected. If there is noone who could work on it
(or not enough people), then the 3D engine will stay a dream for a very long time. Well, unless you
take the JA3 or JAZZ: Hired Guns or a similar engine. But then again, you don't have access to the
source code of these engines and thus the possible modifications would be quite limited.
And by the way, what's wrong with 2D?
III. My Engine
The main ideas of my engine are these.
- replace the current rendering engine as a combination would be impossible (directx -> opengl)
- definition of all elements with local coordinates -> no more global '#define'-crap
- simple setup of all graphical elements
- extensible and replaceable graphical elements
As the topic of this thread are layered sprites, let me use them as an example. You would have
two graphical objects that can render normal sprites and layered sprites. Then you could just replace
old objects with new ones, image by image and animation by animation. You would get a funny mixture
of rendering results in the first place, but at least you have something. You replace the most common
animation first and the least common animations last. Thus the mentioned 'problem' would gradually
go away.
Then there is the objection of why doing the layered sprites stuff anyway if they are going to change
only a couple of pixels on a given object. That is true, but it also doesn't have to stay this way.
We could use larger objects (higher resolution), and i am also thinking about zooming in and out
of the scene, you know, supreme commander style. That would make the visibility problem a lesser problem.
Report message to a moderator
|
|
|
|
|
Re: Improving Original JA2 graphics [message #179459]
|
Sat, 29 March 2008 18:30
|
|
Arethusa |
|
Messages:24
Registered:August 2006 Location: Connecticut |
|
|
BirdFluAnd by the way, what's wrong with 2D?
The biggest problem is extensibility. If I want to make a new gun and add it to the game, it's pretty trivial if it's 3D. I make a model, uvmap it, and skin it. A bit of quick coding for stats following established guns already ingame, and I'm almost there. If I'm feeling exceptionally ambitious, I can make a few animation sets that will be blended into existing animations (ie I'm animating at most parts of the upper body). That's it. With 2D, the process is an excruciating geometric hell of rendering every possible combination by hand.
There are plenty of other problems. It's hard to update. Visibility is bad, especially with the standard set by games like Silent Storm, which may have been far from perfect, but it did do a very good job with a number of things, including its use of 3D. Everything else you said I more or less agree with. I just think people should take a 3D engine more seriously and balance that against a consideration of the enormous disadvantages 2D represents. There's a reason no one uses it anymore.
Report message to a moderator
|
Private 1st Class
|
|
|
Re: Improving Original JA2 graphics [message #179470]
|
Sat, 29 March 2008 19:10
|
|
the scorpion |
|
Messages:1834
Registered:September 2004 Location: CH |
|
|
the reason probably is development ease and speed, (costs) and customer expectations. For many games, it might not even be the looks themselves (3d often looks poor too)
for the characters alone, 3d might be an option. But then, there should be a way to keep the advantages of isometric games, especially the very large maps
in 3d, you either have tiny ranges like in silent storm. i think this is a no-no
or, you have characters at a couple of meters distance look tiny. No-no as well.
so probably the best thing would be if only the characters themselves be a 3d model but with fixed sizes so we'd get the advantages of both systems, iso and 3d.
some hybrid kind of thing if just ja2's animation system is replaced by 3d. But then, layered sprites might have a similar effect, but be more work art-design wise, while the 3d character engine might cause more coding effort.
but that's just guessing. can't judge these things myself.
Report message to a moderator
|
Sergeant Major
|
|
|
|
Re: Improving Original JA2 graphics [message #179472]
|
Sat, 29 March 2008 19:16
|
|
the scorpion |
|
Messages:1834
Registered:September 2004 Location: CH |
|
|
i doubt it. many players hate having to zoom in and rotate cameras and all that crap, that's why they play ISO games.
i personally would want the game perfectly playable without any zoom. Zoom only for showing some details (whatever nature they might be...) to give an additional bonus. But the important design decisions must be taken before the zoom feature comes into play, otherwise you get the same mess many modern games have with their cameras.
Report message to a moderator
|
Sergeant Major
|
|
|
|
|
Re: Improving Original JA2 graphics [message #179505]
|
Sun, 30 March 2008 02:14
|
|
BirdFlu |
|
Messages:438
Registered:September 2007 Location: Lampukistan |
|
|
some thoughts and questions about the 3D engine
1. considering graphics ONLY, what would or should be the difference to, let's say, Brigade E5?
2. what should be the minimum requirements for a possible 3D engine?
3. should the actual game (mapwise) be in 3D or just a subset of it or should it be a whole new mapset?
-> if it is the whole game, then it can't be fully released until ALL maps are converted
4. if there is a 3D engine, then fixing the camera for isometric view is quite simple. It is actually
much simpler than creating an interface for arbitrary viewing directions.
5. don't underestimate the memory requirements for large 3D environments, especially as memory on
graphics board is quite limited (alse see point 2). In 2D you just have a bunch of textures, but
in 3D you have at least the same amount of textures and you also have a lot of geometry data.
6. If you go the 3D way, then you have to convert almost every graphical element (maps, weapons, animations)
to its 3D counterparts. If you stay in 2D you could reuse old stuff and upgrade or replace it gradually.
I would say, that the gradual approach is more motivating for the creators (i.e. US) as you see
that development is moving forward (slowly, but usable all the time) in contrast to the "leap"-approach,
where you have only 20% of the work done and still have to do 80% until you can call it remotely usable.
7. A 3D engine will probaly require a modified or even a new physics engine. Don't know how much work
this would require.
8. I would say a combination of "2D-Background" with 3D foreground elements (weapons, mercs, etc.) is an idea worth
thinking about. I mean we have limited resources and using a simpler approach would probably be more fruitful.
---------------------------
Quote:
Quote:Have you read what Birdflu said earlier about his engine? He is thinking of implementing a Supreme Commander style of zoom interface. That
I believe would solve all the range issues.
That is impossible with 2D. I imagine he was talking about something else.
Why would that be impossible? You have a bunch of texture that you render on a bunch of quads. Zooming in and out
would require some scaling of the quads and use of a mipmapping-mechanism for the textures (so it doesn't look like shit).
Are we talking about the same thing?
Quote:
but then, there would still be the issue with the very limited and outdated JA2 2D engine and especially the very limited color palettes.
it
Report message to a moderator
|
|
|
|
Re: Improving Original JA2 graphics [message #179510]
|
Sun, 30 March 2008 04:56
|
|
Arethusa |
|
Messages:24
Registered:August 2006 Location: Connecticut |
|
|
BirdFluAre we talking about the same thing?
I don't think so. I think you're talking about the ability to switch between tactical and global view, then? Not impossible in 2D (and an exceptionally crude form of this exists in JA2 already), but not very useful, I think, without a much better (3D) engine and graphics implementation.
Anyway, if this is seriously possible and worth discussing, I think we should at some point soon start a new thread specifically for this. Somewhat more importantly, as I don't know this community very well, are there people who knows graphics programming? To call this ambitious is an understatement, and it requires people who know this stuff and have the time to dedicate to it.
Report message to a moderator
|
Private 1st Class
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: Improving Original JA2 graphics [message #179669]
|
Tue, 01 April 2008 03:04
|
|
lisac |
|
Messages:92
Registered:July 2006 Location: Austria |
|
|
Hmmmmm...
@Kaerar: the game is heavily inspired by JA2 and Fallout (Tactics), it's the best match currently I could find to show what I'm up to. 2 or 3 LODs wouldn't bother me (as player), I beleive.
@Lt.Havoc: it's really hard to say how much we can do to make JA2 look like that, but ATM this might be something we're streaming to.
@Khor1255: stop nitpicking, you old fart Yes, it'd go way beyond sprites, I guess.
@Mauser: you're absolutely right. Just don't forget it'd take far less time and work to recreate all static objects (crates, walls, doors...) than our animated beloved heroes containing thousands of animation frames. The biggest problem organizing and leading such a project is my free time. Only thing I can estimate right now is that I'll have more of it in a month or two...
@KeldorKatarn: FIFE is exactly what we need... Graphically. Adapting the current JA2 v1.13 source code to it, especially regarding the LUA scripting system, wouldn't be that easy, don't you think? On the other note, the progress of FIFE development is somewhat slow (slim alpha release up to date), so we'd be very dependent on the FIFE devs and their milestones.
@MarlboroMan: give me a cigarette (although I've quit 8 years ago )...
Seriously, people, don't expect wonders. What we need here are talented coders more than anything (i.e. BirdFlu) - making new sprites can be learned quite fast (in a few hours, with a proper tutorials and tools), and it can be learned by almost anyone (my cousin excluded).
Question for a talented youngster: is it possible to use OpenGL to represent all graphical elements in the game? Examples:
Laptop screen: bunch of textured rectangular polygons.
A ground tile (tactical map): one textured square polygon, put in isometric perspective (iso)
A crate (tactical map): one textured 3D box containing 6 polygons, iso
A chair (tactical map): one textured 3D object containing 40-50 polygons iso
A character (tactical map): one textured 3D object containing 400-500 polygons iso
And I don't want to hear NO as an answer :axe:
Report message to a moderator
|
Corporal 1st Class
|
|
|
|
Re: Improving Original JA2 graphics [message #179673]
|
Tue, 01 April 2008 04:50
|
|
lisac |
|
Messages:92
Registered:July 2006 Location: Austria |
|
|
ArethusaYes, it's possible to recreate everything under opengl.
Yes, theoretically it's possible to represent my grandma's ass using OpenGL too, I know that.
Actually, when I look at that screenshot, I guess BirdFlu has already managed to recreate laptop. What amount of work would be needed to support other objects, like walls, crates, trees..?
Also, what kind of 3D format can be supported within OpenGL? Lightwave's native format is LWO (for objects) and LWS (for scenes and animated objects). We need to think about conversion too...
Report message to a moderator
|
Corporal 1st Class
|
|
|
|
Re: Improving Original JA2 graphics [message #179675]
|
Tue, 01 April 2008 06:20
|
|
Arethusa |
|
Messages:24
Registered:August 2006 Location: Connecticut |
|
|
lisacArethusaYes, it's possible to recreate everything under opengl.
Yes, theoretically it's possible to represent my grandma's ass using OpenGL too, I know that.
Actually, when I look at that screenshot, I guess BirdFlu has already managed to recreate laptop. What amount of work would be needed to support other objects, like walls, crates, trees..?
Also, what kind of 3D format can be supported within OpenGL? Lightwave's native format is LWO (for objects) and LWS (for scenes and animated objects). We need to think about conversion too...
Can you elaborate? As KK said, opengl is just an api. There's a lot of room in there, and I'm not clear on how you would want to implement "support other objects, like walls, crates, trees" or what you specifically mean by that.
Additionally, from personal experience and what I've seen in basically every engine I've ever encountered, editor formats (like the .lw* formats) are not generally suitable for realtime use with games. Depends on a lot of things, though, and exporters are not difficult to come by.
In any case, I also agree with KK that working from an existing engine, even one of the stronger open source projects, may be the most viable route to go with.
Report message to a moderator
|
Private 1st Class
|
|
|
Re: Improving Original JA2 graphics [message #179677]
|
Tue, 01 April 2008 08:04
|
|
KeldorKatarn |
|
Messages:37
Registered:May 2006 Location: Germany |
|
|
This is actually quite easy..
you need to ask yourself one thing first.. do you want the game to be real 3D or 2D
(this doesn't mean hills or 3d terrain or something like that, it means, what ENGINE do you want to use. One can just as well make a tile based 3d engine, but it is a completely differnt approach.
3D Will mostly use meshes for buildings and characters, a 2D engine will mostly use sprites. While sprites can be done with a 3D engine too, using a 3D engine to replicate a 2D game doesn't really make much sense since without 3d objects you cannot use any 3d effects like dynamic lighting, shaders and the like (except postscreen shaders and stuff like that).
If you want to remain true to the game and keep it completely 2D sprite based and just want to improve the graphics, then this is a different thing.
For both solutions I'd really recommend using existing engines. There are engines for both and one can work with both and improve them or modify them for the purpose, but the codebase already exists.
Writing something new is a project that will probably take years.
And the questions about OpenGL... OpenGL is nothing but an API, not more not less. It just offers a simple way to talk to the graphics card, just like direct3D although both API's have a different approach to that.
OpenGl will let you do pretty much anything, as long as you code it.. making walls or treed or backgrounds is not something OpenGL does understand. OpenGL lets you draw lines, points, triangles, colored textured and lit. and that's it. everything else you must program on top of that. THat's what's called an engine. OpenGL is no engine. OpenGL is the tool you write your engine with and engine programming is among the hardest things a game programmer can do.
So depending on what you really want to achieve here, go for an existing engine.
I don't really understand concerns like "we must modify something for LUA support" or stuff like that.. if FIFE has support for LUA.. fine.. nobody forces anyone to use that. From what I see here all that would be used for JA2 would be the graphics, possibly map generation and GUI widget parts.
The only job would be to identify all graphics engine parts of JA2, eliminate them, and replace them by the new engine and adjust the interfaces so they fit together. the game itself should not change one bit.
If you plan to programm an entirely new engine.. to be honest I wouldn't really go that way... but if then I personally would go for a complete port to C#. The language is easier, cleaner and has more IDE support for rapid development and complete Object Oriented approach. Porting the game logic is the smallest part in this and I never tried this becasue porting the engine would be a pain in the butt, so I'd only do that if a complete redevelopment was in order. So if you planned on doing that I'd go this way (oh and please don't anybody start any discussion how games cannot be made in C# and .NET or how C# is a MS toy, go read up on things first before starting a programming language bashing).
I still wouldn't recommend this though since as I said, either way this would be years of work for a 5 man team.
Porting to an existing engine should be easy, and since FIFE was based on the Fallout engine which it seems to be able to replicate already I don't see how this could not be used for JA2.
But the most important question is.. how many people are available for this job?
THis would be a 6 month 5-10 hours a week job for a team of about 5 people which have at least 2-3 years of C++ (AND C!) experience and at least 2 of them should have experience in game and graphics programming to at least understand the new and the old engine and their interfaces.
Report message to a moderator
|
Private 1st Class
|
|
|
|
|
|
Re: Improving Original JA2 graphics [message #179697]
|
Tue, 01 April 2008 14:37
|
|
lisac |
|
Messages:92
Registered:July 2006 Location: Austria |
|
|
I see your point now KK.
Sorry for misunderstood, I thought you're talking about "porting" the current source code completely into FIFE (forgive me for choosing this verb, I'm not a professional coder). If I've understood you correctly, you're suggesting us to take only a part of the existing FIFE code, and that specific one concerning graphics, and to implement it in the JA2 source code. If that's true, then that might be a good option.
Are you fond of the FIFE engine then and to what extent? How about JA2 source code? Anything you could help us with? Anyone you know (or could recruit) for the cause?
Also, what do you think about BirdFlu's idea/progress?
From my point of view (my point of view, as a graphic content creator) I'd always prefer 3D objects over 2D sprites. It takes less time to create it and is a way easier to control, not to mention advanced effects (zoom, lighting, LOD etc.) and the screen resolution problem.
Talking about the whole work... I guess two teams will be needed, the graphic team and the coding one. I can take care about the first one, but in a few weeks only. I believe there's people interested in doing that part of job, and I'm gonna show them how to. The coding group... Well, I can't tell right now, but we need it too.
I surely wanted to say something more, but forgot it. Oh, what the hell...
Report message to a moderator
|
Corporal 1st Class
|
|
|
Re: Improving Original JA2 graphics [message #179702]
|
Tue, 01 April 2008 15:14
|
|
BirdFlu |
|
Messages:438
Registered:September 2007 Location: Lampukistan |
|
|
OK, i downloaded the FIFE engine and looked at it (not too closely).
KaerarThat looks full 3D mate! Is it? I've heard of FIFE before but I can't think of why or where from :s Definitely NOT 3D. Well, not in the sense that it uses 3D-objects.
My thoughts about it are somewhat divided. Sure, it has video, sound, intput and everything (?) what you need to start with.
But it doesn't know anything about JA2 file formats
My 'engine' is more like in a pre-pre-pre-pre alpha stage, but it loads and displays JA2 files (sti [sti-animations], pcx, slf),
has some limited input handling capabilities and has no audio whatsoever.
So far so good (or bad?). Then I looked a little bit closer at the rendering stuff. The FIFE engine uses SDL_Surfaces or
OpenGL textures and the rendering itself is "old-school", that is just drawing a rectangle at a given position. The handling
of all the rectangles (especially visibility determination) has to be done in the 'non-engine'-code, i suppose. As i said,
i have not looked at it too closely, so i may be wrong in some parts. Then i apologize and hope that those, who know better,
can correct me.
I am using a Scene-Graph, which is (as i think) a more modern approach.
And now comes the part where i think that the FIFE angine could give us more trouble than we need.
All the images are saved as single textures and the rendering of basically everything is done in
OpenGL's immediate mode, that is calling glVertex3f, glTexCoord etc.
So, first we don't have multitexturing available, so applying palettes has to be done prior to rendering,
which is not bad by the way, it just consumes approximately four times more video memory.
Second, immediate mode is slow as hell. Honestly, i have to admit that i am using immediate mode as well, but
i plan to change it. The problem is that with large and complex scenes and many very small images you have
to call OpenGL functions too often. And this can really kill rendering performance.
I have seen it in my engine. Depending on how much is actually happening on the screen, i had framerates
between 50 and 2000 fps, and it was just the gui. Rendering a map with a lot of tiny tiles and a huge amount
of little images in immediate mode could bring performance down to one digit framerates, seriously. This
HAS to be taken care of.
BTW, you should not only show the great images
but also the other images, like
Again it is not only the engine that gives great results, it is also the data you use.
Quote:
Question for a talented youngster: is it possible to use OpenGL to represent all graphical elements in the game? Examples:
Quote:Laptop screen: bunch of textured rectangular polygons.
Yes.
Quote:A ground tile (tactical map): one textured square polygon, put in isometric perspective (iso)
Yes. Depends on the data you have. If it is ONE big texture, sure. Beware of exceeding maximum texture sizes.
If you have a lot of "ground elements" you would have to build the texture first.
Perspective, or orientation of the texture in this case, doesn't really matter.
Quote:A crate (tactical map): one textured 3D box containing 6 polygons, iso
Yes and depends. yes for a static crate. A crate that can be opened needs more consideration. can the inside
look like the outside of the crate? Animation itself has to be done and can be done via geometry transformations.
Is the moving part even (one rectangle) or concave/convex (probably more than one rectangle)?
Quote:A chair (tactical map): one textured 3D object containing 40-50 polygons iso
Yes. But 40-50 polygons for static isometric perspective and a texture of not too large size?
Not worth the trouble.
Quote:A character (tactical map): one textured 3D object containing 400-500 polygons iso
Yes. Characters are important. But then again, it depends on your zooming capabilities. Creating
and using polygons that fall on one pixel only is just wasted effort.
----------------------------
Quote:using a 3D engine to replicate a 2D game doesn't really make much sense since without 3d objects you cannot use any 3d effects like
dynamic lighting, shaders and the like (except postscreen shaders and stuff like that).
A 3D engine would OGRE or Irrlicht or something similar. FIFE is a 2D engine, even if it uses a 3D-API.
And just because you don't have 3D objects, it doesn't mean you cannot use dynamic lighting (in the sense of definition).
Postscreen shaders can create some nice effects too.
Apart from all this, OpenGL just undestands vertex coordinates and plain bitmap data (of various formats).
Report message to a moderator
|
|
|
|
Re: Improving Original JA2 graphics [message #179710]
|
Tue, 01 April 2008 16:07
|
|
KeldorKatarn |
|
Messages:37
Registered:May 2006 Location: Germany |
|
|
I still don't quite get where you are really going with this.. are you planning on making this 2D with better graphics or convert to 3D..
if you want to keep it isometric and tile based then I absolutely don't see why a 3d engine is needed.
And the statement that 3d meshes are more easily created than 2D sprites is IMHO a very questionable argument, or simply wrong.
I also do not know why the talk is about a complete game engine with sound, input and everything. Why would that be needed? Ja2 has that already. I thought you just wanted to improve the graphics, so why kick the complete game engine and write that completely new. The rendering part would suffice...
If you guys are actually planning to go full 3D with meshes for everything I'd strongly advise against this. To have a good 3D engine, to design the shaders and effects, to model the meshes and texture them... I don't think you have the people for that, and if this is not done professionally, it will look really ugly.
Not to mention that I see absolutely no need for a full 3D approach. Zooming in is no problem in 2D, games like commandos show that. rotation is not really necessary, and IMO usually confuses the player more than it helps in an isometric game.
Please keep one thing in mind.. 3D graphics ages a lot faster than well done 2D graphics.. look at games like Panzer General. That game still looks ok today, and Panzer General II still looks great except for the resolution. Look then at Panzer General III and IV which introduced 3D engines for the hex-based game.. crappy models, totally blurred textures, horrible interface looks.
Stick to what's natural to the genre. There are lots of great 2D engine games out there. There is no need to make everything 3D just because 3D sounds cool. JA2's entire game mechanics are based on the fact that the game uses an isometric tilebased approach for its game world, and it works great. All that's a little aged is the looks, the resolution and the tiles.
So using a modern 2D engine that is able to use a higher resolution and better lighting (per pixel lighting for the tiles instead of per-tile lighting for example, and a few other effects) will totally suffice.
If you use OpenGL for this, fine, NP, but using OpenGL doesn't mean one has to make 3D models.
Let's say you take (or build) a 2d engine that has nice lighting (e.g using lightmaps and multitexturing for the tiles), supports some nice animated tiles for water and stuff like that, that uses some post-screen shaders for stuff like rain or storm and night, and other stuff, some bloom effects and things will really look great.
I can promise you one thing.. with a good 2d engine you have the chance to bring to near commercial level looks in no time.
In no way will you be able to get this to look commerical level using 3D. for that 3d engine development is way to fast developing and to competitive.
Use sprites but use them well, that's what I'd recommend. Take a good engine (FIFE or whatever else is around) or if you really want to, program one yourself, if you have the people for it, but stick to 2D.
Concerning my personal attitude towards FIFE.. I have nothing to do with it, nor do I use it for anything. I just ran across it a while ago and I was very impressed by it, not so much the looks or the features, since I never tested it or any project using it, but the very professional approach software engineering wise. they have a very very clean code base which is very seldom out there in open source or even commercial country.
About using parts of it or "implementing it into JA2".. I think you really don't know what an engine is really.. you don't take parts of an engine or implement it into anything.. an engine is no game.
An engine is an engine that provides services like rendering, input, sound, scripting, file handling whatever.
WHat I suggested was using the FIFE rendering engine to replace the current JA2 rendering engine (not game.. rendering engine!)
JA2 uses its own engine, a game isn't a complete source thing, it is made up of modules and JA2 is build on top of an engine just like any other game, only that JA2's engine was probably specially written and only used for that game, except unfinished business.
think of an engine as a programming library. it is nothing more. An engine is no application nor is it a game. It offers certain stuff that a programmer can use or not use, depending on what he needs.
I also wouldn't really care about what API the engine is based on, but only on its features and ease of use. THat's exactly what an engine is for. So you don't have to worry about the underlying API crap. If you wanted to worry about that you could have written the stuff yourself.
And I really really doubt the FIFE people have written anything that is going to produce single digit framerates. I didn't really follow your argument in that direction. All I know is, that whoever wrote that code and documentation knows quite a bit about modern software engineering approaches.
Btw.. what a scene graph should be good for in a 2D tile based game, using 3d rendering or not, I do not have the slightest idea, unless you define a scene graph different from what I think of when I hear the term.
WHat the other screenshots was for I don't know either. I didn't post the screenshot to show how great the engine looks, since an engine doesn't look at all. It provides services, it is the game and its ressources that produce the looks.
The screenshot was simply to demonstrate what level of looks for game the engine does support. Every engine in this world can produce crappy looks, even the CryEngine, so I don't really understand what the second screen was for.
That the game has to actually use the features before it looks good should be self-explaining I thought.
[Updated on: Tue, 01 April 2008 16:10] by Moderator Report message to a moderator
|
Private 1st Class
|
|
|
Pages (12): [ 5 ] |
|
Goto Forum:
Current Time: Fri Mar 29 14:11:22 GMT+2 2024
Total time taken to generate the page: 0.03585 seconds
|