03 May 2021, 23:47 | #21 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
|
03 May 2021, 23:54 | #22 |
Registered User
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,153
|
See my edit - turns out it doesn't. As you say, though, setting up an input trap isn't too much of a chore. Last edited by robinsonb5; 04 May 2021 at 00:12. |
04 May 2021, 00:25 | #23 | ||
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
Quote:
|
||
04 May 2021, 00:32 | #24 |
Registered User
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,153
|
|
04 May 2021, 01:15 | #25 |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 881
|
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).
|
04 May 2021, 01:37 | #26 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
Code:
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 |
|
04 May 2021, 01:54 | #27 |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 881
|
|
04 May 2021, 02:45 | #28 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,751
|
Quote:
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. |
|
04 May 2021, 08:48 | #29 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
Quote:
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. |
||
04 May 2021, 10:04 | #30 | |||
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Quote:
Quote:
|
|||
04 May 2021, 10:15 | #31 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 47
Posts: 3,751
|
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.
|
04 May 2021, 10:25 | #32 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
But I'll also look to do the OpenScreen method too and see how I get on. |
|
04 May 2021, 10:40 | #33 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
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. |
04 May 2021, 11:38 | #34 | |||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
Quote:
Nope, it disregards good programming practise. The Os is a hardware abstraction layer. Even for the subtle differences of AGA, ECS and OCS. Quote:
For me, this sounds like a silly exclude for being sloppy. |
|||
04 May 2021, 11:46 | #35 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
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? |
|
04 May 2021, 11:59 | #36 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
Quote:
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. |
|
04 May 2021, 12:01 | #37 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 53
Posts: 4,468
|
Quote:
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. |
|
04 May 2021, 12:04 | #38 | |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,215
|
Quote:
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. |
|
04 May 2021, 12:31 | #39 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,863
|
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...
|
04 May 2021, 12:34 | #40 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,408
|
Quote:
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 |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
REQ: NoiseTracker or ProTracker System friendly source | redblade | Coders. Asm / Hardware | 4 | 27 February 2021 08:56 |
Cool e-ink display for 30 euro. Amiga friendly? | TenLeftFingers | support.Hardware | 3 | 11 November 2016 12:21 |
System friendly Protracker Replay? | AGS | Coders. System | 2 | 16 August 2014 20:53 |
Any Screen grabers HighGFX friendly? | NovaCoder | support.Apps | 4 | 17 December 2009 13:50 |
Assembler System Friendly code | redblade | Coders. General | 3 | 29 July 2008 12:15 |
|
|