R&D locls up

Found a bug in R'n'D? Report it here!

Moderators: Flumminator, Zomis

Post Reply
perplexed

R&D locls up

Post by perplexed »

Im having a problem with RD locking up at random times. I compiled it on a Solaris 9 system using gcc 3.4.1. I've also downloaded packaged version of it but they also lock up. Anybody have any ideas why this is happing?thx
Flumminator
Posts: 184
Joined: Fri Jun 18, 2004 8:08 pm
Location: Germany

Post by Flumminator »

> Im having a problem with RD locking up at random times.

How dows it lock? Does it consume all CPU-time or none? Does the screen get repainted if you move another window over it or not?

Did you compile the X11 or SDL version?

In the meantime I'm gonna downgrade my Sun and try to reproduce it ;)
Flumminator->PostCounter += 1;
perplexed

lock ups

Post by perplexed »

The screen wont get repainted if i move to another window. I run top at the same time and the cpu utilization is real low for the RD processes. There are two rockand diamonds processes both go to sleep when the game locks up. I compiled it using X11, I tried and still am trying to get it to compile using SDL but i run into some lib problems relateing to SDL. Thanks for the help :D
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

Hmm, that sounds strange (and such behaviour was not reported before so far).

Although I check (at least) compilation under Solaris from time to time, I have never seen this (but I did not run it for a very long time, just quickly checked that everything looks fine). Unfortunately, I have not much access to Sun systems at the moment, as my new employer better likes a Windows dominated environment at work. (At least I have an additional Linux box to prevent me from going crazy. ;-) )

Does that lockup happen after a shorter or longer time period?
Does it also happen when just waiting in the main menu, or only when playing a level?
Can you start the program using 'strace' and watch the last function call before it dies?
perplexed

lock ups

Post by perplexed »

It happens at random times somtimes i can even get past a level before it locks up. So far it only locked up when im playing a level. I used truss in solaris and it should the process is writeing i assume its doing the level recording. Also I was able to get it to compile with SDL and it appears to be working fine been through a couple levels and no lock ups. I must have something to do with X11.
Flumminator
Posts: 184
Joined: Fri Jun 18, 2004 8:08 pm
Location: Germany

Post by Flumminator »

sorry, i couldn't reproduce it. but I've only tested it with gcc 3.4.2, because I've found a ready package for this ;)

Maybe I'll compile gcc 3.4.1 and try it again.

Holger: btw. when playing some levels I had to find out that I couldn't place dynamite with the default-settings, because my sun-keyboard lacks a right ctrl-key ...

And the background of the status-window to the right (i.e. the non-animated part) seems to be in some weird colors, but that might be a compilation problem, I remember having compiled RnD on Solaris before where all was ok...
Flumminator->PostCounter += 1;
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

> Holger: btw. when playing some levels I had to find out that I couldn't place dynamite with the
> default-settings, because my sun-keyboard lacks a right ctrl-key ...

That's the right time for custom-defined key settings! :-)

I understand that the default settings are a bit of a problem on a Sun keyboard in this case. Are there any problems to just define the "drop key" to be "Alt Graph", "Compose" or the "Sun" ("Diamond"?) key on the right side of the "Space" key?

(In previous versions, the "snap" and "drop" keys were the left and right "Shift" keys, but I then decided to change this to the left and right "Ctrl" keys, as this seemed to be more obvious or usual to me when using a "standard" PC keyboard...)

> And the background of the status-window to the right (i.e. the non-animated part) seems to
> be in some weird colors, but that might be a compilation problem, I remember having compiled
> RnD on Solaris before where all was ok...

Can you reproduce this and provide me with a screenshot? Maybe I can see of what kind the problem might be here... :-/
User avatar
bojster
Posts: 458
Joined: Fri Jun 18, 2004 7:42 pm
Location: Poland
Contact:

Post by bojster »

Holger wrote:(In previous versions, the "snap" and "drop" keys were the left and right "Shift" keys, but I then decided to change this to the left and right "Ctrl" keys, as this seemed to be more obvious or usual to me when using a "standard" PC keyboard...)
Did I miss something? I use shifts since forever and nothing changed for me... maybe it's the matter of using the old settings. Well anyway, I think that shifts are better for at least two reasons: they're bigger (wider) and I have always used them in pinballs ;-)
Good thing, though, that you can customize then, but then again, people rarely do that...
Hm... now that I think about it, I recently changed right shift to Z, to spare moving left hand between the sides of the qwerty keyboard. Maybe LCtrl and LWin would be a better choice after all... I think I can live with anything actually, just a matter of getting used to.
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

> Did I miss something? I use shifts since forever and nothing changed for me...
> maybe it's the matter of using the old settings.

Exactly. If you started with an older version and ever saved any settings, they will continue to be used in newer versions, even if the defaults change to something different. Anything else wouldn't be very userfriendly, I think. ("New version! Guess the current key settings!" ;-) )

> Well anyway, I think that shifts are better for at least two reasons: they're bigger (wider) and
> I have always used them in pinballs ;-)

But the left Ctrl key is wider than the left Shift key. :-)

I changed it because I thought that the Ctrl keys are easier to access without looking after them, as they are placed at the very bottom-left and bottom-right on most keyboards.

> Good thing, though, that you can customize then, but then again, people rarely do that...

Yeah, right...

> I think I can live with anything actually, just a matter of getting used to.

At least I don't want to force people to get used to something they don't like...
Flumminator
Posts: 184
Joined: Fri Jun 18, 2004 8:08 pm
Location: Germany

Post by Flumminator »

> That's the right time for custom-defined key settings!
Guess what I did ;)
I was just a bit surprised, because I had hit some keys and no dynamite was placed, then I looked at the keyboard to search the right CTRL and ... found none.

> Are there any problems to just define the "drop key" to be "Alt Graph",
> "Compose" or the "Sun" ("Diamond"?) key on the right side of the "Space"
> key?
all work fine.

>> And the background of the status-window to the right (i.e. the non-animated part) seems to
>> be in some weird colors, but that might be a compilation problem, I remember having compiled
>> RnD on Solaris before where all was ok...
As I already thought, it was completely my fault, because the X-Server was running on only 256 colors...

@perplexed: sorry, couldn't reproduce the lockups
Flumminator->PostCounter += 1;
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

> As I already thought, it was completely my fault, because the X-Server was running on only 256 colors...

Oops... Long time ago that I last tested R'n'D on a 256 color display (may be an old Sparc Station at the university). It seems that support for 8-bit color depth just ran out. :-o

(So it seems that the color mapping for this case in the R'n'D X11 version either does not work very good, or that most colors were already eaten up by other desktop applications, or ...)
Post Reply