Using LoadView to display a system friendly title screen?

[ross]

Originally Posted by robinsonb5

But would you expect Intuition to notice that its view has been replaced and stop responding to input as a result?

[robinsonb5]

Originally Posted by ross

See my edit - turns out it doesn't. As you say, though, setting up an input trap isn't too much of a chore.

[ross]

Originally Posted by robinsonb5

EDIT: OK I just tested it, and yes, input events do reach the underlying screen after LoadView(NULL) has removed the system copperlist.

Both keypress and mouse events on hidden windows?

Originally Posted by robinsonb5

A couple of other points:
LoadView(NULL) should be followed by a couple of WaitTOF() calls before loading your own copperlist, and you should store GfxBase->ActiView first, and LoadView() that on exit - that way RTG screens should (should!) be correctly restored too.

Yep, this as usual

[robinsonb5]

Originally Posted by ross

Both keypress and mouse events on hidden windows?

Yes indeed - I did LoadView(NULL), a 10 second delay, then restored the display.
While the screen's hidden I can activate other windows, and type into them.

[alpine9000]

As well as registering an input handler to null out any input events, you would also probably want to set the pr_WindowPtr of the current Process/Task to -1 to stop any requesters silently waiting behind the screen. Don't forget to restore the pr_WindowPtr pointer as well when you're done (if it's not already -1).

[ross]

Originally Posted by alpine9000

As well as registering an input handler to null out any input events, you would also probably want to set the pr_WindowPtr of the current Process/Task to -1 to stop any requesters silently waiting behind the screen. Don't forget to restore the pr_WindowPtr pointer as well when you're done (if it's not already -1).

Yep, this is in my trap events handler and contain pr_WindowPtr=-1 setup:

	include LVOs.i
	include exec/execbase.i
	include	exec/tasks.i
	include dos/dosextens.i
	include	devices/input.i
	include	devices/inputevent.i


trap_events

	movea.l	$4.w,a6
	lea	ioreq(pc),a4
	movea.l	ThisTask(a6),a5

	; hide possible requesters since user has no way to
	; see or close them.
	moveq	#-1,d0
	movea.l	pr_WindowPtr(a5),a3	; oldwinptr
	move.l	d0,pr_WindowPtr(a5)

allocSignal
;	moveq	#-1,d0
	jsr	_LVOAllocSignal(a6)
	move.b	d0,sigbit-ioreq(a4)
	bmi.b	nosig
	move.l	d0,d7

gotsignal
	move.l	a5,sigtask-ioreq(a4)

	; open input.device
	lea	inputname-ioreq(a4),a0
	moveq	#0,d0
	moveq	#0,d1
	lea	(a4),a1					; ioreq
	jsr	_LVOOpenDevice(a6)
	tst.l	d0
	bne.b	nodev


	; install inputhandler
install
	lea	(a4),a1					; ioreq
	jsr	_LVODoIO(a6)

;**************************
.ll	move.w	$dff006,$dff180
	btst	#6,$bfe001
	bne.b	.ll
;**************************
	
	; remove inputhandler
	lea	(a4),a1					; ioreq
	move.w	#IND_REMHANDLER,IO_COMMAND(a1)
	jsr	_LVODoIO(a6)

	lea	(a4),a1					; ioreq
	jsr	_LVOCloseDevice(a6)

nodev
	move.l	d7,d0				; sigbit
	jsr	_LVOFreeSignal(a6)

nosig
	move.l	a3,pr_WindowPtr(a5)	; oldwinptr
	moveq	#0,d0
	rts


ih_code
	move.l	a0,d0
.loop
	cmpi.b	#IECLASS_TIMER,ie_Class(a0)
	beq.b	.skip				; keep only TIMER events
	clr.b	ie_Class(a0)		; #IECLASS_NULL
.skip:
	move.l	(a0),a0
	move.l	a0,d1
	bne.b	.loop
	rts							; d0 is the original a0


ioreq
	dc.l	0,0				; LN_SUCC, LN_PRED
	dc.b	NT_REPLYMSG,0	; LN_TYPE, LN_PRI
	dc.l	0				; LN_NAME
	dc.l	msgport			; MN_REPLYPORT
	dc.w	IOSTD_SIZE		; MN_LENGTH
	dc.l	0				; IO_DEVICE
	dc.l	0				; IO_UNIT
	dc.w	IND_ADDHANDLER	; IO_COMMAND
	dc.b	0,0				; IO_FLAGS, IO_ERROR
	dc.l	0				; IO_ACTUAL
	dc.l	0				; IO_LENGTH
	dc.l	ih_is			; IO_DATA
	dc.l	0				; IO_OFFSET

ih_is
	dc.l	0,0				; LN_SUCC, LN_PRED
	dc.b	NT_INTERRUPT,127; LN_TYPE, LN_PRI ** highest priority ** 
	dc.l	0				; LN_NAME	;ihname
	dc.l	0				; IS_DATA
	dc.l	ih_code			; IS_CODE
	
msgport
	dc.l	0,0				; LN_SUCC, LN_PRED
	dc.b	NT_MSGPORT,0	; LN_TYPE, LN_PRI
	dc.l	0				; LN_NAME
	dc.b	PA_SIGNAL		; MP_FLAGS
sigbit
	dc.b	-1				; MP_SIGBIT
sigtask
	dc.l	0				; MP_SIGTASK
.head
	dc.l	.tail			; MLH_HEAD
.tail
	dc.l	0				; MLH_TAIL
	dc.l	.head			; MLH_TAILPRED
	dc.b	NT_MSGPORT,0	; MLH_TYPE, MLH_pad

;ih_name
;	dc.b	'trap-events',0
inputname
	dc.b	'input.device',0

	even

I keep the TIMER events, I remember having problems otherwise.

[alpine9000]

Originally Posted by ross

I keep the TIMER events, I remember having problems otherwise.

Interesting - I haven't done that - but can't see the harm in adding it

[Thorham]

Originally Posted by mcgeezer

As I've tried to explain... I am short on chip ram, I don't want to allocate upwards of 64kb for a bitmap when I already have that ram available in a previous allocation to load and unpack files from.

You don't have to. If you already have the raw bitplane data in chipmem ready for displaying, then you can tell OpenScreen()/OpenScreenTagList() to use that memory for opening the screen instead of having it allocate memory itself.

Alternatively, you can let OpenScreen()/OpenScreenTagList() allocate the memory, and then you can simply load/unpack the bitmap directly to that allocated memory (note that these functions don't necessarily allocate one chunk of memory, but can allocate each bitplane separately when memory is fragmented).

Both these methods require no extra memory and are much easier than setting up a screen from scratch.

This is probably what Thomas Richter was trying to explain.

[Thomas Richter]

Originally Posted by mcgeezer

As I've tried to explain... I am short on chip ram, I don't want to allocate upwards of 64kb for a bitmap when I already have that ram available in a previous allocation to load and unpack files from.

First of all, wrong approach. You let graphics/intuition do the allocation, and then use that memory for your graphics. I already said that there are alignment restrictions on bitmap memory that depend on the chip generation and the screen mode. Second, even if you allocated the memory yourself (hopefully with AllocBitMap()), you can provide this information to intuition to create a screen from you. But see above - this makes usually little sense.

Originally Posted by mcgeezer

My question was simple, can I use LoadView() to point to a simple copper list that I previously created... it seems the answer is "no"... that's all you had to say instead of jabbering on.

No, the ansower is "your approach is wrong". Please rethink.

Originally Posted by mcgeezer

Also, when I take over the system I do a call to Disable(), when the game is done I make a call to Enable() and release all ram and everything comes back fine, minutes may have passed during the interval.

That is not guaranteed. Please see the RKRMs. Some hardware (but probably not yours) does require regular interrupts. The RKRMs (and that is the important reference) state that you can only disable for a couple of milliseconds. I do not recall the precise number, but it's specified.

[mcgeezer]

Originally Posted by Thomas Richter

First of all, wrong approach. You let graphics/intuition do the allocation, and then use that memory for your graphics. I already said that there are alignment restrictions on bitmap memory that depend on the chip generation and the screen mode. Second, even if you allocated the memory yourself (hopefully with AllocBitMap()), you can provide this information to intuition to create a screen from you. But see above - this makes usually little sense.

I'd agree with you if I were writing an Amiga OS application, however I'm not so my approach is right given the memory constraints I am under. And no I don't use AllocBitmap because I don't have to, I can quite easily align the memory myself with my in game routines.

Originally Posted by Thomas Richter

No, the ansower is "your approach is wrong". Please rethink.

No, my approach is fine. You have several other programmers in here that are using an easier and viable alternative for the very problem I faced. I simply don't have the RAM available for me to bend and agree to "your approach is wrong" statement.

Originally Posted by Thomas Richter

That is not guaranteed. Please see the RKRMs. Some hardware (but probably not yours) does require regular interrupts. The RKRMs (and that is the important reference) state that you can only disable for a couple of milliseconds. I do not recall the precise number, but it's specified.

This comes back to the question I raised earlier in the year about game dev's having to support every bit of hardware plugged into a system, I've had this argument before, game dev's who want to have all hardware resources simply don't worry about it. If gamers don't like it, then they can unplug the hardware and run the game from a floppy.

[Thorham]

Originally Posted by mcgeezer

I'd agree with you if I were writing an Amiga OS application, however I'm not so my approach is right given the memory constraints I am under.

You have the bitmap in chipmem, so just use OpenScreen() to open a screen using that memory. What's the problem with that? It doesn't use up extra memory.

[mcgeezer]

Originally Posted by Thorham

You have the bitmap in chipmem, so just use OpenScreen() to open a screen using that memory. What's the problem with that? It doesn't use up extra memory.

Because I've had three people come back to me and say they use the LoadView(null) method.

But I'll also look to do the OpenScreen method too and see how I get on.

[ross]

I would not do the OpenScreen() method for one reason only: it is by system and therefore can be patched.
So in the end you can have a screen promoted, shifted or whatever it is.

I have seen ugly positioned opening screens many times due to default settings.
Of course, everything can be recalculated and fixed, but why make your life difficult?
In any case, the game takes control of the system shortly after ...

If you want a consistent loading screen with your game, the 'hardware' method is much simpler and more effective.
But of course OpenScreen() also works.

[Thomas Richter]

Originally Posted by mcgeezer

I'd agree with you if I were writing an Amiga OS application, however I'm not so my approach is right given the memory constraints I am under.

Why does that make any difference? Once again, you need the same amount of memory in either case. The bitmap has a certain size, and that costs a certain amount of memory. No matter who allocates that.

Originally Posted by mcgeezer

And no I don't use AllocBitmap because I don't have to, I can quite easily align the memory myself with my in game routines.

Then chances are that the alignment isn't right. The system is there to help you get things right.

Originally Posted by mcgeezer

No, my approach is fine.

Nope, it disregards good programming practise. The Os is a hardware abstraction layer. Even for the subtle differences of AGA, ECS and OCS.

Originally Posted by mcgeezer

If gamers don't like it, then they can unplug the hardware and run the game from a floppy.

It boils down to the question whether people can play your game. Well, if you don't care that it runs anywhere, why would anyone care to play it at all?


For me, this sounds like a silly exclude for being sloppy.

[Thomas Richter]

Originally Posted by ross

I would not do the OpenScreen() method for one reason only: it is by system and therefore can be patched.
So in the end you can have a screen promoted, shifted or whatever it is.

Frankly, this is exactly the reason why it *should* be used. The user set preferences, and adjusted the screen to fit on the monitor. With rolling everything on your own, including the copper list, all the user preferences are ignored. Shouldn't a wise program accept the choices made by its user?

[roondar]

Originally Posted by Thomas Richter

Then chances are that the alignment isn't right. The system is there to help you get things right.

Alignment requirements are hardly rocket science. They're also well documented. And getting them wrong instantly results in a corrupted screen.

You do this a lot with regards to OCS/ECS/AGA chipset stuff. You pretend it's all mystical and unknown and only the OS knows how to do it properly and all other ways end in disaster. It's just not true. I seriously wonder about your motivations in making these, frankly, absurd claims.

[ross]

Originally Posted by Thomas Richter

Frankly, this is exactly the reason why it *should* be used. The user set preferences, and adjusted the screen to fit on the monitor. With rolling everything on your own, including the copper list, all the user preferences are ignored. Shouldn't a wise program accept the choices made by its user?

It's just a matter of context, and mcgeezer's one is precisely circumscribed.
Either mcgeezer makes a fully system compliant game, and then he adapts to the user's settings, or the whole game immediately presents itself with its own video features to which the user adapts.

Otherwise, a soup comes out that doesn't make much sense.
If the chosen path is that (for several reasons) then follow it to the end.

You can be right in general and when considering a program that follows the system, but not in this specific.

[Thomas Richter]

Originally Posted by roondar

Alignment requirements are hardly rocket science. They're also well documented. And getting them wrong instantly results in a corrupted screen.

You do this a lot with regards to OCS/ECS/AGA chipset stuff. You pretend it's all mystical and unknown and only the OS knows how to do it properly and all other ways end in disaster. It's just not true. I seriously wonder about your motivations in making these, frankly, absurd claims.

So what's the motivation of this, frankly, absurd programming practise? Saving memory isn't. It's less system friendly - that's the only thing - and that's rather a disadvantage.

[StingRay]

I "like" how this turned into yet another "only 100% OS legal programming is the way to go, everything else is bad and should be banned at all costs" thread...

[roondar]

Originally Posted by Thomas Richter

So what's the motivation of this, frankly, absurd programming practise? Saving memory isn't. It's less system friendly - that's the only thing - and that's rather a disadvantage.

Let's see... One is a programming style that you can disagree with, but that is actually quite defensible in the current context (which you didn't even attempt to understand).

The other is a prominent Amiga OS coder constantly misinforming people about how difficult the HW is to access and use (and that's me putting it extremely nicely), rather than just saying "I don't think you should do that" and leaving it at that.

Guess which one I find more problematic. Here's a hint: if you think it's the programming style, you're dead wrong