Using LoadView to display a system friendly title screen?

[mcgeezer]

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.

 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

[Thomas Richter]

Originally Posted by mcgeezer

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.

[mcgeezer]

Originally Posted by Thomas Richter

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.

[Thomas Richter]

Originally Posted by mcgeezer

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?

Originally Posted by mcgeezer

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.

[mcgeezer]

Originally Posted by Thomas Richter

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.

[Rotareneg]

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

[Thomas Richter]

Originally Posted by mcgeezer

What do you mean exactly by opening a screen?

I mean intuition OpenScreen()/OpenScreenTagList().

Originally Posted by mcgeezer

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.

[mcgeezer]

Originally Posted by Thomas Richter

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.

[Thomas Richter]

Originally Posted by mcgeezer

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.

[mcgeezer]

Originally Posted by Thomas Richter

*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.

[kamelito]

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

[ross]

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

[Asman]

@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.

[mcgeezer]

Originally Posted by ross

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

[ross]

Originally Posted by mcgeezer

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.

[StingRay]

Originally Posted by ross

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).

[mcgeezer]

Originally Posted by ross

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.

[robinsonb5]

Originally Posted by ross

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.

[ross]

Originally Posted by robinsonb5

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?

[robinsonb5]

Originally Posted by ross

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.