We seem to have made progress in this discussion although it was advancing on a parallel rail rather than perfectly on topic.
I feel being forced to be more verbose and I should apologise to those who love short notes.
Now I shall not wade into simulations such as Sim City more than just mentioning it for reflection.
Please recall any game that comes with an editor to grasp the concepts.
1- There is a basic land size option.
2- There is a basic pallet for the terrain and water types which are based on bitmap tiles.
3- There are land/ sea options which you may overlay the scenery with.
4- There are static or non-functional graphic features that do not register hot points detectable by mouse pointer.
5- Finally you add the active graphics coordinates to which the user may interact or is being automated by software.
On the other side of this issue we have a graphics card that comes with a special type of memory accessed by the graphics processor to display its contents.
I shall discard my case where my system can display 1600 x 1200 pixels at full 32 bit colour descriptors.
So let us visit the standards.
Larian Studios was quite professional on the resolution choices to cover the market.
640 x 480, 800 x 600 and 1024 x 768 are the standard three resolutions we have around.
Now let us investigate the limits of demanding RAM.
1024 x 768 x 16 bit colour for (565) technique was quite a professional choice.
This means that each screen you see demands 12,582,912 bytes or 12 MB for short.
It so happens that we can define a virtual screen with a much higher resolution and swap memory content in a flash of time the first upper level is 4 visible screen tiles with a total of 48 MB.
The second upper level is 9 visible screen tiles totalling 108 MB.
Now read carefully.
In this situation you have a screen right in front of your eyes and 8 screens ready for scrolling and inspection. With a 128 MB RAM you have 20 MB available for system dynamic link libraries and your game. Some graphics cards come with 32, 64 or 128 MB of Video-RAM, which means that the system is relieved from being concerned about the place in which to place the graphics.
Once your character becomes technically inside a new screen some programmers on sensing that condition reconstructs the set of nine screens and that is a very bad decision.
A much better technique is the mini-map and the virtual border; with all your graphics elements resident in RAM you only need to update the hidden border as your character advances in coordinates without any loading from media during runtime. This means that your virtual screen may be only slightly bigger than the standard resolution such as 1200 x 1000 x 16, which is only 19.2 MB.
Some programmers prefer to use 80 x 80 graphic background tiles while others prefer a 64, 92 or 128 squares for addressing issues, but all should do fine.
The divinity wizard male is the largest graphics description files and they total 172 MB; now that may not be in RAM of course so how does the programmer use those files.
We all know that a character could be standing, walking, running or fighting and simply those files contain all such 3D animations. This fact dictates and demands LOADING data in real time from media to use in the game. There is a technical error made by L.S. in which they keep full graphics of 3D which absolutely unnecessary because you cannot rotate the world. North, South, East and west are fixed for the background.
Your character may be ordered to move in any direction in 360 degrees but only 8 gifs are required per status of motion (Standing, walking, running and fighting), so we are talking about 32 gifs but we need to consider the armour/ weapon combinations too. And here is the dilemma; can those bitmaps be saved statically beside the image lists used for constructing worlds?
Advanced techniques may save the day by applying skins and motion skeletons as well as making house construction sets RAM resident. This means that you shall see your character holding the correct weapon image rather than a standard axe for all axes. <img src="/ubbthreads/images/graemlins/winkwink.gif" alt="" />
This means that you shall see fabulous armour and style sets being animated on the fly.
So rather than wasting the power of your CPU in data transfer between media and RAM the CPU power shall be dedicated to calculate the skins wrapping the skeleton in a specific direction of motion to create a specific gif on the fly and voila. <img src="/ubbthreads/images/graemlins/winkwink.gif" alt="" />
That is why I complained from the fact that <img src="/ubbthreads/images/graemlins/div.gif" alt="" /> had hundreds of useless weapons and Swen already acknowledged this problem and :rift; shall have less but more unique and fabulous weapons. <img src="/ubbthreads/images/graemlins/up.gif" alt="" />
Random battlefield generators mean that no static libraries shall ever be in service of the game in the way it was in <img src="/ubbthreads/images/graemlins/div.gif" alt="" />.
So what do we have here now with such very advanced programming technology; we have a graphics construction set rather than
Pre-rendered gifs (animated clips).
We have one animation queue to fill rather than 8 at a time and we can do it
On The Fly.
If the game demands 64 MB RAM and put every skin and skeletal description in that RAM then you have a fabulous performance that was absolutely impossible on the Z80 Sinclair.
A Pentium III running at 500 MHZ with 128 MB RAM is a very fair demand today.
The data bus never runs at the high frequency of the processor but typically runs at 33 or 66 MHZ only.
Thus, even the RAM data transfers are not as fast as you might believe it is or should be.
Now, by applying THIS advanced programming technology, we eliminate data loading at runtime completely and we do not need to worry about the performance of hard disks CDs or DVDs at runtime.
The music data Stream may be channelled to the audio card to run concurrently and without any supervision keeping the DVD running and hot for an audio-wave clip on demand.
Finally, we may have a bonus of video clips at the end of each act or even at critical quest-completion events to run directly from DVD, and we shall never experience any jerks of any sort whatsoever.
When the game starts, it needs to read a tiny configuration file to setup the resolution appropriately and nothing more. Occasionally you would want to save your game and rather than saving 48 MB for each game you only need to save key information, which is mainly significant numbers for counting things and saving coordinates of those things. My estimate is below 1MB of memory for each save.
So, mainly, our discussion included arguments passing over heads, because I never endorsed the current programming techniques, which demand installation on hard disks as an obvious solution.
My proposal was to adopt a much more advanced programming technology to get rid of hard disk runtime loading dependencies. I believe that Larian Studios are on their way to do just that even though in steps or in a little bit different way.
Read the latest interview with Swen and you shall catch the drift.
Cheers.
