O.K. so I was working on my Star Wars project for PrBOOM/PrBOOM +/Odamex last night and put my files onto my Morph machine for testing.

I had not messed with PrBOOM under MorphOS much before, and am having some issues.

First and foremost, why port PrBOOM and not PrBOOM +? Seriously!!! ;)

O.K. for my real question.

Why in the world would PrBOOM of all games suck up ALL my GFX RAM? Even if I did not have all MorphOS's eye candy turned off, it still should not do this.

The reason I know it is doing this is because when I press my Right Mouse Button in game, I get dumped back to MorphOS's main screen and have to press the button in the upper left hand corner of the screen to get back to my game.

Also, how do I turn off the feature that insists that I must have one mouse button assigned to move the character forward. Even if I comment out the option in the config file, it comes back. My temporary option has been to assign that and srafe to the mouse wheel which does not get used.

Lastly, the game runs great, but when the intermission screens, and loading screens are horribly slow! Slower than when there used to be a working port for the Nintendo DS. Something is seriously wrong here. I'm on an eMac after all with 1.5Gb of RAM which I'd say is over kill.

Any thoughts?

Also any idea if Gl is on the way for PrBOOM? I guess AROS has it on the way...

> Why in the world would PrBOOM of all games suck up ALL my GFX RAM?
> Even if I did not have all MorphOS's eye candy turned off, it still should not
> do this. [...] when the intermission screens, and loading screens are horribly
> slow! [...] Something is seriously wrong here. I'm on an eMac after all with
> 1.5Gb of RAM which I'd say is over kill. Any thoughts?

Works fine here on Mac mini G4 with 64 MiB VRAM, even in 1680*1050 resolution.

I have no idea what this Prboom thingy is :D

First about the mouse issue. The easiest way is to simply add an input handler which eats unwanted key and mouse events, so the system cannot react on them. Best way is to combine with a window active/inactive detection, so your handler is only filtering when the focus is on your game.

About VMem, there are several reasons:

1. 32MB are quite small. 1600x1200 in 32 bit eats already around 8MB. Each screen in that resolution will. Your game and the Ambient screen. All Icons, toolbars and other images eat additional memory. The backdrop eats memory. Invisible memory alignments eat gfx memory. Even the mouse pointer eats around 64KB vmem AFAIK.

2. The 2.7 graphics driver does not support AGP mode. Which mean swapping between system and vmem is quite slow. 2.8 will probably bring a huge boost here (if the agp drivers will be included)

3. VMem memory handling is far from being perfect.

I had the opportunity to work on a 32MB Vmem Mini a few weeks ago and the gfx memory is a pain in the ass even with 1280x960. Try to reduce Ambient screen size, remove dektop icons to gain some speed boost.

Another option may be to use 16 bit colors only. This will double the free video memory instantly.

Geit



[ Edited by geit 22.06.2011 - 14:25 ]

@Geit:

Actually, there is no reason to use inputhandlers since MorphOS 2.x comes with a proper and faster replacement for this obsolete functionality.

See intuition/intuition.h WM_ObtainEvents. Also, it's possible to get raw (unaccelerated/unfiltered) mouse movements from IDCMP messages - see intuition/intuimessageclass.h

> I have no idea what this Prboom thingy is :D

http://downloads.morph.zone/find.php?find=prboom

> Another option may be to use 16 bit colors only.

PrBoom uses 8-bit screen anyway :-)

http://prboom-plus.sourceforge.net/

And there is the source to the latest incarnation of PrBoom Plus in case anyone is interested. It also has GL and Freelook support. If no one shows interest in porting this update, then I'll probably start a bounty as it would be worth it to me as a Doom Dev.

How come my classic Amiga, using large screen modes, playing Doom and such does not kill my meager 2mb of. gfx ram?

Quote:

Because on classic amigas the chipram is so painfully slow that it's faster to just handle everything in fastmem and only copy the final result to chipram.

Hmm, well I probably have no idea what I am talking about, but wouldn't it make more sen sense to not change things and continue to spare the GFX RAM like Amiga OS does?