my turn

[cowsmanaut]

well for once I actually *played* RTC.. for longer than 3 mins anyway.. as a result I noted a few things that kind of bug me so I'll whine now..

1. Gothmog is the last member in my party and he seems to get this green box around his 'eye' in the the backpack. it does not go away and it doesn't have any purpose

2. The cloak of darkness can be worn around the neck as well but you've not implimented this yet. It makes sence as this is typically where one wears a cloak so removing this feature doesn't seem right.

3. a minor detail with screamers and rockpiles and a few other monsters like those squishy snot rags.. anyway.. the thing is that sharp objects stick in them daggars and arrows have a high chance of becoming their 'attire' as it were. They are returned to you when the monster is dead.

4. That box around the objects REALLLLLYYY needs to be enlarged.. it's almost frustrating when trying to get things done. Also order of pick up is not a rule.. by that I mean if you can see it you can pick it up.. ie. The white shirt and the grey key.. I could not pick up the white shirt untill I got the key due to the order of them. However this doesn't make sence .. if the box of the shirt is larger than the key's then it should 'peek out' from behind it and be 'clickable'

well that's all I can remember for now..

the biggest bug of all is the speed of the game which it seems to be linked to how much Ram you have.. more you got that faster tha game..

anyway.. cheers

[George Gilbert]

> Gothmog is the last member in my party and he seems
> to get this green box around his 'eye'

The eye is shown green when a characters stats are boosted (i.e. when you've gained a level or drank a potion). Unfortunately it appears this includes boosting due to wearing the cloak of night! Me thinks that's a bug then...

> The cloak of darkness can be worn around the neck

Really??? Coo - I never knew that (which is why it isn't implemented). Well you learn something new everyday...

> sharp objects stick in [some monsters]

Ah yes - had forgotten about that.

> that box around the objects

Fixed that last night - there was a minus sign in the wrong place...

> the biggest bug of all is the speed of the game which
> it seems to be linked to how much Ram you have.. more
> you got that faster tha game..

Unfortunately that's life I'm afraid. RTC has a massive memory footprint (there's about 30MB of graphics stored - large 24bpp bitmaps eat it up very quickly!); if it can't all be stored in RAM at once then the frame rate is going to be killed off before you even start trying to do anything else...

[cowsmanaut]

Yeah I understand the need to support the graphics after all DM for amiga wanted a full meg and ofcourse the game itself fit on a single disk which is less than a meg.. what is it like 730k or something.

is there no way of lowering that 30meg mark by loading only needed things to mem? Do like Dm and do a load between levels if new things are needed and get rid of unneeded things?

I have no problems really but those with less ram that I know get frame rates at 4-6fps at best. There must be a way of speeding it up.. but how? They way you are doing the transperancies is as fast as it can go the drawing to screen seems to be good since there is no visable retrace at least not that I've noted.. it must be something obscure.

Perhaps you should put up annother section of the chat board for Programming. Explain in basics (I know you can't show most of your code) what you've done and see if some people here can give some more insight..

Put a few of these minds to work..

[Gambit37]

How about limiting all graphics to their own 8-bit (or less) palette? You'd still need to run in true colour mode, but all graphics would be significantly smaller.

For example, a sword only has a few colours in it. Even if I designed a new one that used many different colours, this could probably be optimised to be represented by say, 32 colours.

Can this be done or does everything need to be 24-bit?

[George Gilbert]

Hmm - if the screen is in 24bpp (which it needs to be really for shading etc) then all the graphics have to be in that mode too. Storing them in a lesser mode would probably slow the game down more (as it would have to convert them to 24bpp before blitting them onto the screen on every refresh).

Storing only a small number of graphics at any one time could be the way forward and would certainly ease the memory requirements, but is a pain to programme with a significant delay when changing levels (like the ST version had). In any case most graphics are needed most of the time (in DM the only things that were loaded at the start of each level were the doors, some wall items and monsters); unfortunately these make up only a small fraction of the total stuff that's in memory at any time...

By doing some optimising of the graphics scaling I can probably save about 10-20% space, but really that's the wrong ball park (to make an appreciable difference the memory would have to come down by about 75-90%).

[cowsmanaut]

is there a way of doing a hack compression that doesn't compress much but can be decompressed realtime?

if somethings not used it's then compressed..?

grrr.. there must be something.. (bangs head for inspiration)

something needs to be done or else sound will kill this thing..

either way every little bit counts .. a little here a little there.. nibble nibble..

[Gambit37]

Could always use a fixed 8-bit palette I suppose, but then half the game would have to be re-coded, and it wouldn't leave much flexibility for really great looking graphics, or fancy features

There must be something that could be done - I agree Drake - when sound's added it could really kill performance of RTC...

Hmmm... thinking caps on.

[beowuuf]

Unless someone thinks of somehting revolutionary, I don't think slamming at the compression, etc is the way to go - something more lateral is needed here...

*coiugh*...did I mention I wasn't a programmer *cough*

I can't believe something that is only 1Mb can, if not cripple, but soooo reduce the perfornance of a machine. Is there any trade offs for actual disk space that can be slackened, etc? I know hard drives aren't the fastest, but can virtual memory for half these things be used instead as a buffer so the information is already uncompressed ahead of time but isn't tying up the RAM?

*cough*...did I mention I wasn't a programmer *cough*

Hopefully thinking why that is a bad suggestion might make the brain realise something sneaky that wll....

[George Gilbert]

Everything is already decompressed and put into virtual memory (that's why it takes so long to load!)...the problem is that it's so large it spills over into windows swap space and that's when it all goes horribly wrong.

[amaprotu]

This might be a bit more work but it might dramatically improve performance. In the original DM there had to be graphics for every distance and position of wall, because scaling would have taken up much of the precious CPU cycles and 8bit graphics don't take up much space. In this case it seems that the problem is with too much graphics space requiring using the swap space on the hard drive which is slowing it down, not the actual CPU time. If this is the case would it be possible to implement it so that there is only 1 wall graphic loaded that is scaled and shaded and skewed appropriatly for the section it is drawn in? This combined with loading monsters / wall items between levels could make it run a lot smoother. But I admit it would be a lot of work, if its not impossible, and may not be worth the gains for the time to implement.

- Amaprotu <p> <a href="http://www.icq.com/icqtour/webcomm.html"><img alt border="0"src="http://online.mirabilis.com/scripts/onl ... e.gif"></a> AMAPROTU
<p><a href="http://msg.mirabilis.com/scripts/contac ... 7004"><img altborder="0" height="23" src="http://www.jps.net/amaprotu/wot/icqme.gif" width="88"></a><ahref="mailto:2667004@pager.mirabilis.com,amaprotu@jps.net"><img alt border="0" height="23"src="http://www.jps.net/amaprotu/wot/email.gif" width="87"></a><ahref="http://web.mirabilis.com/scripts/srch.d ... 7004"><img alt border="0"height="23" src="http://www.jps.net/amaprotu/wot/zoom.gif" width="87"></a></p></p>

[George Gilbert]

Fixed all of this (hopefully) for V0.05