English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 03 May 2021, 16:10   #1
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,356
Using LoadView to display a system friendly title screen?

In my project I want to keep the system operational but display a title screen from a copper list I've constructed.

Is it possible to just create a View structure and call Loadview() on it..? Or do I really have to create a ViewPort as well?

Any examples would be handy too.

Code:
 STRUCTURE	  ViewPort,0
   LONG	   vp_Next
   LONG	   vp_ColorMap
   LONG	   vp_DspIns
   LONG	   vp_SprIns
   LONG	   vp_ClrIns
   LONG	   vp_UCopIns
   WORD	   vp_DWidth
   WORD	   vp_DHeight
   WORD	   vp_DxOffset
   WORD	   vp_DyOffset
   WORD	   vp_Modes
   BYTE	   vp_SpritePriorities
   BYTE	   vp_reserved
   APTR	   vp_RasInfo
   LABEL   vp_SIZEOF


   STRUCTURE View,0
   LONG	   v_ViewPort
   LONG	   v_LOFCprList
   LONG	   v_SHFCprList
   WORD	   v_DyOffset
   WORD	   v_DxOffset
   WORD	   v_Modes
   LABEL   v_SIZEOF
mcgeezer is offline  
Old 03 May 2021, 17:19   #2
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,150
Quote:
Originally Posted by mcgeezer View Post
In my project I want to keep the system operational but display a title screen from a copper list I've constructed.

Is it possible to just create a View structure and call Loadview() on it..? Or do I really have to create a ViewPort as well?
You need the viewport for the copper lists, and you also need a ViewExtra for extended screen modes. But frankly, leave this low-level junk aside, and let intuition do the work for you. As soon as you have your own view, it means that this interacts badly with the rest of the system.



Screen front/back hotkeys will erase your view, there will be zero chances to promote your application to any other screen mode than the native ones.



Just open a screen. You can hide the drag bar, so there is no visible difference to a view, except that things work nicely.
Thomas Richter is offline  
Old 03 May 2021, 17:33   #3
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,356
Quote:
Originally Posted by Thomas Richter View Post
You need the viewport for the copper lists, and you also need a ViewExtra for extended screen modes. But frankly, leave this low-level junk aside, and let intuition do the work for you. As soon as you have your own view, it means that this interacts badly with the rest of the system.



Screen front/back hotkeys will erase your view, there will be zero chances to promote your application to any other screen mode than the native ones.



Just open a screen. You can hide the drag bar, so there is no visible difference to a view, except that things work nicely.
Thanks for your reply.

I'll add some context...

My executable is 200kb, once that is loaded by the system I then wanted to load a simple game loading image and display it in a OS friendly manner because I need to use the OS to load the rest of the game. Once the game is loaded then full take over of the system ( Disable(), OwnBlitter() etc ) is done then released when the game ends.
mcgeezer is offline  
Old 03 May 2021, 17:39   #4
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,150
Quote:
Originally Posted by mcgeezer View Post
Thanks for your reply.

I'll add some context...
Use a screen. Really. I'm serious.



For rolling a display yourself, you need a RasInfo, a ViewPort, a ColorMap, a View, and a ViewExtra. Then associatate the ViewExtra to the view, load colors, MakeVPort(), MrgCop(), LoadView().


It is *really really* a lot more hassle than to open a screen, and put a backdrop borderless window on it so nobody can drag it away. Actually, intuition does all the same, but in a fully integrated way without having to worry about the gory details.



Is there a particular reason why you want to make it more complicated, plus prime chances to shoot yourself in the foot?



Quote:
Originally Posted by mcgeezer View Post

My executable is 200kb, once that is loaded by the system I then wanted to load a simple game loading image and display it in a OS friendly manner because I need to use the OS to load the rest of the game. Once the game is loaded then full take over of the system ( Disable(), OwnBlitter() etc ) is done then released when the game ends.

You cannot disable for more than a couple of ms safely if you want to return to a working system.
Thomas Richter is offline  
Old 03 May 2021, 17:50   #5
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,356
Quote:
Originally Posted by Thomas Richter View Post
Use a screen. Really. I'm serious.



For rolling a display yourself, you need a RasInfo, a ViewPort, a ColorMap, a View, and a ViewExtra. Then associatate the ViewExtra to the view, load colors, MakeVPort(), MrgCop(), LoadView().


It is *really really* a lot more hassle than to open a screen, and put a backdrop borderless window on it so nobody can drag it away. Actually, intuition does all the same, but in a fully integrated way without having to worry about the gory details.



Is there a particular reason why you want to make it more complicated, plus prime chances to shoot yourself in the foot?






You cannot disable for more than a couple of ms safely if you want to return to a working system.


What do you mean exactly by opening a screen? I know the very basics of the AmigaOS, do you mean there is an easier OS friendly way to display a simple image on screen?

The other sticking point I have is that I am very low on chip ram, I really don't want the OS to start allocating ram ... I was hoping I could get away with just allocating the ram for a copper list and load the image into a buffer that is already under my control.

This is looking more tedious than it should be, I'll just skip the game having a loading screen.
mcgeezer is offline  
Old 03 May 2021, 19:49   #6
Rotareneg
Registered User
Rotareneg's Avatar
 
Join Date: Sep 2017
Location: Kansas, USA
Posts: 235
If you're trying to make it OS friendly, try using CloseWorkBench() and OpenWorkBench() to free up and then restore Workbench afterwards if you need the extra ram. Then just open a regular Intuition screen for your game: http://amigadev.elowar.com/read/ADCD.../node00D7.html
Rotareneg is offline  
Old 03 May 2021, 20:14   #7
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,150
Quote:
Originally Posted by mcgeezer View Post
What do you mean exactly by opening a screen?
I mean intuition OpenScreen()/OpenScreenTagList().


Quote:
Originally Posted by mcgeezer View Post
The other sticking point I have is that I am very low on chip ram, I really don't want the OS to start allocating ram ...
And the RAM for the bitmap falls from the sky if you use LoadView()? OpenScreenTagList(), the CloseWorkBench(), and you have the RAM back.
Thomas Richter is offline  
Old 03 May 2021, 20:25   #8
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,356
Quote:
Originally Posted by Thomas Richter View Post
I mean intuition OpenScreen()/OpenScreenTagList().



And the RAM for the bitmap falls from the sky if you use LoadView()? OpenScreenTagList(), the CloseWorkBench(), and you have the RAM back.
You know can i just say you have a bad attitude in your replies. i’m not sure what i’ve done to you to warrant your “falling from the sky” amongst other repsonses you spew out. You can either help me or not, totally up to you... if not then dont bother replying.

Assigning memory from a copper list will surely be smaller than allocating ram for a huge bitmap - i already explained i already have the ram allocated for the bitmap under my control, i dont want to allocate it again.
mcgeezer is offline  
Old 03 May 2021, 21:18   #9
Thomas Richter
Registered User
 
Join Date: Jan 2019
Location: Germany
Posts: 1,150
Quote:
Originally Posted by mcgeezer View Post
Assigning memory from a copper list will surely be smaller than allocating ram for a huge bitmap - i already explained i already have the ram allocated for the bitmap under my control, i dont want to allocate it again.

*Sigh* In case this was not clear to begin with: OpenScreen() and friends will allocate the same amount of chip ram for the bitmap than you would have to allocate, except that you have to do a lot more footwork, plus the risk to do it wrong. There is nothing to "allocate again". OpenScreen allocates the memory for you - and you find this memory in screen->RastPort.BitMap and the bitmap pointers therein.



There is really an Os to do the work for you, with tested and working functions. It does not make sense to re-invent the wheel. The Os knows the corner cases of the chipset, its quirks, such as alignment requirements on the bitmap, independent on the chipset revision and the host system.
Thomas Richter is offline  
Old 03 May 2021, 21:32   #10
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,356
Quote:
Originally Posted by Thomas Richter View Post
*Sigh* In case this was not clear to begin with: OpenScreen() and friends will allocate the same amount of chip ram for the bitmap than you would have to allocate, except that you have to do a lot more footwork, plus the risk to do it wrong. There is nothing to "allocate again". OpenScreen allocates the memory for you - and you find this memory in screen->RastPort.BitMap and the bitmap pointers therein.



There is really an Os to do the work for you, with tested and working functions. It does not make sense to re-invent the wheel. The Os knows the corner cases of the chipset, its quirks, such as alignment requirements on the bitmap, independent on the chipset revision and the host system.

Not all of us do everything through the OS, if this (sigh) offends you then maybe move swiftly on to another thread.

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.

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.

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.

Last edited by mcgeezer; 03 May 2021 at 21:38.
mcgeezer is offline  
Old 03 May 2021, 21:57   #11
kamelito
Zone Friend

kamelito's Avatar
 
Join Date: May 2006
Location: France
Posts: 1,388
This source load an iff image and display it.
It was many images instead of actual text that I typed into a usable source code.
http://obligement.free.fr/articles/a...images_iff.php

Last edited by kamelito; 03 May 2021 at 22:32.
kamelito is offline  
Old 03 May 2021, 22:17   #12
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 51
Posts: 3,283
Hi Graeme, I'm not entirely sure why you want to use a View structure.

What I would do is simply call LoadView(NULL) and then directly write my copper list pointer to COP1LC.
Then use the value at GfxBase->copint (offset $26) to restore it at the end.
The system is fully active with your copper list in use

Someone will turn up their noses because this is unorthodox..

EDIT: sorry, corrected

Last edited by ross; 03 May 2021 at 22:36.
ross is offline  
Old 03 May 2021, 22:38   #13
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 776
@mcgeezer
I think that you can do it in following way:

1. save old view
2. reset display
3. io flush
4. loading assets
5. io flush
6. takeover os

I am not sure if I did it in Solomon's Key. But for sure I have source code with loading data with loading screen and very simple progress bar. I need to dig it up. Probably tomorrow I will send you pm.

Last edited by Asman; 03 May 2021 at 22:39. Reason: added missing step after loading assets
Asman is offline  
Old 03 May 2021, 22:42   #14
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,356
Quote:
Originally Posted by ross View Post
Hi Graeme, I'm not entirely sure why you want to use a View structure.

What I would do is simply call LoadView(NULL) and then directly write my copper list pointer to GfxBase->copint (which the system uses for the initialization copper list), offset $26.
Save the old value and then restore it at the end.
The system is fully active with your copper list in use. It is the system itself that uses it

Someone will turn up their noses because this is unorthodox..

Hi Ross - thanks for this as it looks like it will work quite easily.

So here is the reason I was looking at the View structure, it may be that I'm over complicating what I need.

My Turbo Sprint exe is roughly 200kb, when the exe is loaded it then allocates 392kb of ram - this ram becomes under my control to allocate things like screen buffers, sprite sheets etc. But upon load I use it to load a 320kb file which has all of the game assets in a packed format. So as I have 72kb remaining in the buffer I thought I would load a title screen for the game while the 320kb assets load from floppy/hd (using DOS calls).

So then because I have the system up and running I need to simply load a title screen image into the back of the 392kb buffer (title screen is 5 bitplanes.. approx 50kb in size so enough space). I then just need to display the image... so the only thought I had was that I would have to use LoadView to create a custom COPPER list which points to my bitplanes and RGB pallette.

If there's an easier way to do it then I've missed it... but the upshot is I need to display the title screen while I do a call to Open(), Read(), Close() etc.

Hope this makes sense... appreciate the response buddy!

Graeme
mcgeezer is offline  
Old 03 May 2021, 22:47   #15
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 51
Posts: 3,283
Quote:
Originally Posted by mcgeezer View Post
Hi Ross - thanks for this as it looks like it will work quite easily.

So here is the reason I was looking at the View structure, it may be that I'm over complicating what I need.

My Turbo Sprint exe is roughly 200kb, when the exe is loaded it then allocates 392kb of ram - this ram becomes under my control to allocate things like screen buffers, sprite sheets etc. But upon load I use it to load a 320kb file which has all of the game assets in a packed format. So as I have 72kb remaining in the buffer I thought I would load a title screen for the game while the 320kb assets load from floppy/hd (using DOS calls).

So then because I have the system up and running I need to simply load a title screen image into the back of the 392kb buffer (title screen is 5 bitplanes.. approx 50kb in size so enough space). I then just need to display the image... so the only thought I had was that I would have to use LoadView to create a custom COPPER list which points to my bitplanes and RGB pallette.

If there's an easier way to do it then I've missed it... but the upshot is I need to display the title screen while I do a call to Open(), Read(), Close() etc.

Hope this makes sense... appreciate the response buddy!

Graeme
Check my edit, it's even easier

I also happened to write directly to GfxBase allocated memory for copinit, so I mixed things up a bit..
(this works also, but hmm too much brutal and limited.., only for some dirty job)

Try as I wrote in the edit, it should work.

ross is offline  
Old 03 May 2021, 22:49   #16
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,652
Quote:
Originally Posted by ross View Post
Someone will turn up their noses because this is unorthodox..

Unorthodox or not, it works. I've used this approach back in the day (TM).
StingRay is offline  
Old 03 May 2021, 22:50   #17
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,356
Quote:
Originally Posted by ross View Post
Check my edit, it's even easier

I also happened to write directly to GfxBase allocated memory for copinit, so I mixed things up a bit..
(this works also, but hmm too much brutal and limited.., only for some dirty job)

Try as I wrote in the edit, it should work.

Thanks man - will do.
mcgeezer is offline  
Old 03 May 2021, 23:21   #18
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,031
Quote:
Originally Posted by ross View Post
Someone will turn up their noses because this is unorthodox..
I'm not turning my nose up - because this is probably how I'd do it, too - but just bear in mind that you're only hiding the underlying workbench screen. It's still there, and if you haven't frozen the system, it's also responding to keypresses and mouseclicks.
In theory a careless user who's absent-mindedly clicking around while waiting for the game to load could click the "Yes" button of that "Really format volume Work:" dialog he carelessly left open!

For that reason, I'd probably also install an input handler to soak up keypresses or mouse movements.
robinsonb5 is offline  
Old 03 May 2021, 23:29   #19
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 51
Posts: 3,283
Quote:
Originally Posted by robinsonb5 View Post
I'm not turning my nose up - because this is probably how I'd do it, too - but just bear in mind that you're only hiding the underlying workbench screen. It's still there, and if you haven't frozen the system, it's also responding to keypresses and mouseclicks.
In theory a careless user who's absent-mindedly clicking around while waiting for the game to load could click the "Yes" button of that "Really format volume Work:" dialog he carelessly left open!

For that reason, I'd probably also install an input handler to soak up keypresses or mouse movements.
A trap input handler is easy to install, but are you sure that mouse input goes to the Workbench below when I have a View(NULL) in the foreground?
ross is offline  
Old 03 May 2021, 23:37   #20
robinsonb5
Registered User
 
Join Date: Mar 2012
Location: Norfolk, UK
Posts: 1,031
Quote:
Originally Posted by ross View Post
A trap input handler is easy to install, but are you sure that mouse input goes to the Workbench below when I have a View(NULL) in the foreground?

Not 100% sure, no - my memory may be playing tricks on me, so I'd have to try it. But would you expect Intuition to notice that its view has been replaced and stop responding to input as a result?

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

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.

Last edited by robinsonb5; 03 May 2021 at 23:53.
robinsonb5 is offline  
 


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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 09:16.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.12428 seconds with 14 queries