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.

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.

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.

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

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.

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

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

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

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

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.

:great

Unorthodox or not, it works. I've used this approach back in the day (TM).

Thanks man - will do. :great

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?

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.