Messages

va!n: You should have received a reply from blueberry by now.

Call transformations are enabled using the /TRANSFORM:CALLS switch. The CALLS part identifies that it is the call transformation you want to use, which is currently the only one, not which type of opcodes to transform. By rereading the description I realize that it can be slightly ambiguous. Maybe we should consider rewriting it for the next release.

Good luck with your project,
-mentor

stormbringer:
Great, you just had me scrap a rather lengthy rant about the arrogance that is the ordfarts of the demoscene :/

I will behave myself and just note that what constitutes "the golden days" depends on the beholder. What you refer to as "the golden days" were golden because you were active at that time and the productions that you consider outstanding are so, because you can reminisce about them. Regardless of what happens in the future, it will never quite be the same as the time when you first got into the scene. Not because of the quality of releases, the spirit of the scene, the use of hardware, etc, but because of you. Not that you are any worse in this matter than anyone else.

To me, there is nothing golden or magic about your golden years, and I know little about the outstanding productions of that time. If I see them I will probably not be able to appreciate them, as they are from your golden time, not mine. I propose that we from now on refer to the period december 2000 (the release of fr-08, followed by an era of exceptional 64k intros) and beyond as "the golden years".

Now let's kiss and make up

Motorheap: couldn't agree more.

Shockwave: Make that at least 5. It is obviously true that using a graphics api is easier than writing everything yourself, I don't see anyone saying otherwise. Doing the same stuff is thus of course easier. The point is that people are not just doing the same tired old things. They are moving on and spending their time on more challenging techniques. It can be more advanced rendering, texture generation, realtime synthesizers, content creation tools, whatever.

I honestly don't believe that 3d coding is easier today, considering that the bar has been raised more than enough to compensate for not having to do vertex operations and rasterizisation of triangles yourself. This is of course assuming that you want to create stuff that is on par, if you are satisfied just rotating a cube, then things are of course way easier.

24 and I feel old :/

How about making a production that compares by todays standards. we are talking a real demo, 64k or 4k, not just
some starfield with a scrolltext . When you have done this, come back and tell me with a straight face that:
1. No one optimizes their code anymore, they just buy a bigger PC.
2. Demo coding is a dying art
3. Coding new effects is 'easier' than in the golden years.
4. Making a size limited productions is only a matter of api hacking.
5. Random incoherent rant about sprites and starfields.
6. ...

It is true that things are 'easier' now in the sense that a spinning cube or a scrolltext is trivial to code and make it run sufficiently fast. The thing is, people don't just make spinning cubes and scrolltexts anymore (at least some don't). I honestly believe that the bar is higher today and creating something that is on par takes a lot more skill and creativity than in 'the golden years'.

Having a fixed platform in terms of speed is not something that is ever going to happen on the PC. Taking into account the hardware used and the speed, one can usually judge the 'quality' of the code. People wanting hard limits go for 4k intros or console demos. No wonder 4k coding has become so popular recently, right?

Maybe ageing makes me become and extremist (hehe)... who knows. I just have the feeling that very few of the new prods will be remembered, even by the new generation. They all look like commodities and are just made to be consumed. The old-school generation, however, remembers with great pleasure, some significant productions released in the old days. Weird isn't it?

Couldn't agree more. Most productions will be forgotten, some 'significant' productions will be remembered. It was true then, it is true now. I think your nostalgia makes you severely underestimate the amount of bad and mediocre productions in 'the golden years'. With several thousand productions, don't tell me they were all memorable. Will productions like fr-08, kkrieger, debris, lifeforce, heaven seven, starstruck, chaos theory, the popular demo, etc. not be remembered?

Which 256b intros require directx? what 700mb package do you need to watch directx intros? windows xp?

I might be a little 'extreme' here, but this oldfart'ery is making me barf.

Ok, your scheme seems reasonable well thought out. Here are some of my thoughts.
-Why have a pointer to the library name, when you could just as well have the name there itself.

-Using a full word to signal the end of a list seems a bit excessive, if the list is not meant to be compressed. You could use a byte counter instead.

-Addition is a commutative operator, so any permutation of the string will give the same result, which is obviously not a desirable property for a hash function . Besides, you are not really distributing the names very well, as most names will have roughly the same length and sum. Having multiple checks, like length and sum, is probably not so good either, if you want to keep things tiny.

In crinkler we use a simple xor-rotate scheme, where new characters are xor'ed into the hash and rotated. This is obviously not commutative in general.

Code Select Expand


;esi: ptr to name
xor edi, edi
.hashloop:
rol edi, 6
xor eax, eax
lodsb
xor edi, eax
dec eax
jge .hashloop
;edi:hash code


Some other stuff to think about:
-If you are already hacking the PE and have some annoying unused fields left, why not use them to store some hashes? Interpreting non-hashes as hashes is not a problem, if you never call the 'fake' imports - so why not just import the whole PE header?

cheers
-mentor

you are pretty much right about everything.

the hash is basically a fingerprint of the function you want to import. you hash the one thing that is guaranteed not to change across windows versions, the name. There can be collisions, but if your hash function is good and you allocate sufficiently many bits for your hash codes, this will never occur in practice.
Collisions between functions in different dll files is not a problem, if you associate each hash with only one dll.
You can always choose some hash function without collisions for the version of the dll files that you have got.
The only thing that can really go wrong then is that another function is introduced into a dll with a name hashing to the same as some function you are importing.  Assuming that your hash is perfect and 32-bit, the probability of a new function colliding with one of the m functions you are using is m*2^-32. Even if a bunch of new functions are introduced, this is still negligible.

The ordinal of a function is an integer that is guaranteed to uniquely identify the function within the dll file. This is usually just the index of the function. These ordinals can (and will) change with windows versions and is thus not a particular safe importing mechanism.

ROXOR: No, it is a horrible hack.

Cheers
-mentor

rain_storm: For a final release build I would recommend something like this.

/COMPMODE:SLOW
Slow compression really isn't that slow anymore - there really is no reason not to use it.

/HASHSIZE:100-200
Indicates how many megs of ram will be used for decompression. Note that the decompression
memory overlaps with the static memory of the intro, so the memory requirement of the compressed binary
ends up being max(hashsize, static memory used by intro). If the hashsize is smaller you can essentially
raise it to the memory usage of the intro for free. A larger hashsize is always better, but the law of diminishing
returns kicks in fast after the 100-200mb mark.

/HASHTRIES:500-1000
Indicates the number of tries made to find a good hash function minimizing collisions. Higher is better, it will only cost you CPU cycles.

/ORDERTRIES:5000-?
Indicates the number of tries at different layout of the code/data. The impact of a good layout can be quite dramatic, so spending some extra time here can often pay off. The iteration will converge at some point, mostly depending on the number of sections in the intro. Try out some different values to see when there are no more improvements. Again, setting it too high will only cost you CPU cycles.

/UNSAFEIMPORT
Disables the warning message that appears if a dll file is missing. The rule of thumb is: If you are not using d3dx9_xx.dll, you are safe to use /UNSAFEIMPORT.

/TRANSFORM:CALLS
Transforms relative calls (E8) to absolute calls to improve compression. Enabling this feature gives a small overhead of ~20 bytes, so whether or not it is worth it really depends on the number of calls and how they are distributed. Try both and choose whichever is best.

Cheers
-mentor/TBC

Jim: I have recently made the switch to VC2008 myself without experiencing any problems. As far as i can tell, the generated .obj files are nearly identical to those generated by VC2005. Have you by any chance forgot to disable link time code generation?

Cheers
-mentor/TBC