   Old Gamedev articles?
  I was just reading an article here about resource files when the author said one disadvantage of resource files is that they're heavy on the RAM. And then went on to say: "Nonetheless, this is a trivial problem, especially considering that most PC's now ship with at least 64 megabytes of RAM"At which point i was like, wtf? I scrolled down and the article was written 10 years ago. I then looked up all the other articles i read, and they all seem to be at least 6 years old.Anyway, i was wondering if these articles are still 'valid'? Or should i google something newer?The reason i'm asking is because i'm a beginner and really don't know how much things evolve in the wonderful world of programing.. But i think for example resource files are still resource files right?   
  Right! Programming in general is moving forward quickly, so a 10 year old article is pretty much outdated today. Almost everyone uses resource files nowdays.   ;Quote:At which point i was like, wtf? I scrolled down and the article was written 10 years ago. I then looked up all the other articles i read, and they all seem to be at least 6 years old.Anyway, i was wondering if these articles are still 'valid'? Or should i google something newer?Yes, and no.Computers evolve quickly, so does knowledge. But often, it just adapts. And sometimes, you have to learn what is no longer true, and what is new.Some papers are very old, yet we still discover new applications, or the computational power from today makes them possible.For example, HDR as we know it today was invented around 1993 and started becoming possible on games around 2004 (some may argue the dates, but the point is, it's old).Atmospheric Scattering to render skies and planetary engines was invented back in 1993 too, but it's still making progress today towards making real time practical applications. I could keep naming techniques the whole day, some of them which were invented even before I was born.Respect the articles here in GD.Net, well, it may be true that some are obsolete, but for example using resource files still has the same problems as before.10 years ago it was cool that PCs were shipping with more than 64 MB RAM, but a regular bmp file was around 200kb.Currently we just scaled the situation, we have 4GB RAM, and 7 "HD" JPEG file which is abour 3MB each.The ratios aren't the same of course, (0.2MB/64MB = 0.003 while  0.021GB/4GB = 0.00225) and still an executable with resource heavy data sometimes takes forever to load (have you tried double clicking an exe installer that is 700MB?)Here's an interesting article to review. It talks about accelerating alpha blending with MMX.This article is almost completely obsolete. MMX is an obsolete, deprecated instruction set. Now GPUs do a much better job here, so today we aren't trying to squeeze the hardware to alpha blend a 1280x720 image (the article talks about 640x480!) and mainly we're now memory bandwidth limited, rather than ALU limited (which is what SIMD tries to solve).But there is one important element in that article: the logic still applies.The vital part of that article is not how to improve performance with MMX (probably that was the point back then) but rather how the formula was modified in a clever way to do the operation as a fast as possible.This is an extreme case, because that article almost has no point today. But it's still interesting and you can extract something useful from it.Of course theres the other extreme, for example the 1500 archers article is still much very valid. I think 99% of it remains valid, yet was it written in 2001, discussing the multiplayer networking algorithm used for Age Of Empires I.CheersDark SylincEdit: Christian Weis has a point that nowadays everyone uses resource files. It's something you don't think twice. But you can still abuse the system and put very large files on it.   ;  Thanks for the thorough reply :)   ;  You may want to check the Gamedev wiki. I don't know how much information it contains these days, but chances are it's more up-to-date than the articles section.   