Using LoadView to display a system friendly title screen?

[ross]

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.

I reply, but I think it is so obvious to many in the forum that they will not even bother to do so.
Amiga is a limited platform and the system slows you down or does not leave you complete freedom for some choices.
(you could argue that it slows you down only a little and that it leaves you a lot of freedom, but this is also relative )

Mcgeezer's game can be done completely system compliant? Probably yes.
Can it be done in a vanilla multitasking environment with limited memory? No.
So he just does what everyone has done in the past and continues to do right now: take control of the system and abuse it at will.
(which by the way is also pleasant to do )

That's all. Get over it .

[Thomas Richter]

Originally Posted by roondar

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

If you don't like the answer, why ask? The answer is that there are conditions under which your proposal doesn't work. I state them.

Originally Posted by roondar

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.

The question is not "how difficult it is", but "how can I avoid trouble", and "which trouble is ahead of me".

Originally Posted by roondar

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

I afraid not. Your approach to solve a problem is troublesome, because you make certain assumptions on the system that simply don't hold, and are documented not to hold. You ignore them - ok. But then don't ask for advice if you don't like the answer that the way how you approach the problem is not guaranteed to work.

[roondar]

Originally Posted by Thomas Richter

If you don't like the answer, why ask? The answer is that there are conditions under which your proposal doesn't work. I state them.

I didn't ask a question about using the OS, I observed you routinely tell people falsehoods about accessing the hardware directly and wondered aloud why you keep doing that.

The question is not "how difficult it is", but "how can I avoid trouble", and "which trouble is ahead of me".

Which is fair enough, but not relevant because what you're doing here is something very different. It's one thing to tell people that there's trouble ahead and another to basically tell lies to try and get people to comply with your ideal way of doing things. The latter is what you're doing.

I afraid not. Your approach to solve a problem is troublesome, because you make certain assumptions on the system that simply don't hold, and are documented not to hold. You ignore them - ok. But then don't ask for advice if you don't like the answer that the way how you approach the problem is not guaranteed to work.

The assumptions hold just fine, the Amiga is a dead system that has been static for nearly 30 years now. Anyone claiming differently is deluding themselves. This is also why, despite your many, many claims to the contrary most modern games and demos for the Amiga just, well, work - and usually on a very large range of Amiga's at that. Despite doing things all "wrong".

[Thomas Richter]

Originally Posted by roondar

Which is fair enough, but not relevant because what you're doing here is something very different. It's one thing to tell people that there's trouble ahead and another to basically tell lies to try and get people to comply with your ideal way of doing things. The latter is what you're doing.

Please identify the "lie" thing. Thank you.

[mcgeezer]

I'm wondering Thomas, all of the previous Amiga games programmers who created games for the platform, was their programming all absurd too when they took over the system and didn't do everything via the OS?

[Thomas Richter]

Originally Posted by mcgeezer

I'm wondering Thomas, all of the previous Amiga games programmers who created games for the platform, was their programming all absurd too when they took over the system and didn't do everything via the OS?

It certainly causes a lot of problems such as: I cannot run games from the workbench, games crash with hits, games don't work with my graphics card and games don't work with my 68060. Please don't tell me, I see these problems. If things had been done properly, the software would run on the machine "as is", in the screen modes I select, and with the 68060 in place.


The approach of the "early years" certainly was to see the Amiga as a glorified games console, with the programming practice of the 8-bit area applied to a machine that was designed to be extensible and grow beyond its limits. This is probably understandable as a historic accident, and people didn't know better. But years have past, documents have been written, the Os improved. I see little reason to continue such bad practise nowadays, where the material is all available, the problems are known, and a much richer platform than in the old days is out in the hands of the user.


It is just sloppy, and the platform deserves better.

[kamelito]

I guess that if AmigaOS did provide from the start a very fast library or more for games, programmers would have used it/them but even with the latest OS release such thing doesn’t exist. It doesn’t matter anymore as the Amiga is walking dead
That being said adventure games, card games etc are suitable candidate to OS compliant game programming.

[roondar]

Originally Posted by Thomas Richter

Please identify the "lie" thing. Thank you.

I already did.

"Then chances are that the alignment isn't right." is false. And as an OS coder, you know it is false because he can't display working screens at all if the alignment it wrong (and he obviously already knows how to do that considering he released working AGA software before).

Originally Posted by kamelito

I guess that if AmigaOS did provide from the start a very fast library or more for games, programmers would have used it/them but even with the latest OS release such thing doesn’t exist.

Absolutely. I have nothing against the OS, but it's not very good at unlocking the HW potential of the system. Especially on the low-end models, where it's impossible to get the results we ended up having without chucking the OS.

[DMWCashy]

The whole point in people making modern Amiga games is to really push that hardware as far as they can. Using a once great but massively outdated OS makes no sense, the argument is mute.
Now if a Modern highly optimised OS was developed then maybe this argument would have a little more merit.

[mcgeezer]

Originally Posted by Thomas Richter

It certainly causes a lot of problems such as: I cannot run games from the workbench, games crash with hits, games don't work with my graphics card and games don't work with my 68060. Please don't tell me, I see these problems. If things had been done properly, the software would run on the machine "as is", in the screen modes I select, and with the 68060 in place.


The approach of the "early years" certainly was to see the Amiga as a glorified games console, with the programming practice of the 8-bit area applied to a machine that was designed to be extensible and grow beyond its limits. This is probably understandable as a historic accident, and people didn't know better. But years have past, documents have been written, the Os improved. I see little reason to continue such bad practise nowadays, where the material is all available, the problems are known, and a much richer platform than in the old days is out in the hands of the user.


It is just sloppy, and the platform deserves better.

There you are again... telling me my programming and attitude is sloppy... it's not, if I was being sloppy I'd not bother making any OS calls at all and whack the system completely and use a track loader etc.

You seem to not even consider the constraints I'm working under in the game and just wildly call my programming sloppy. I'll take sound advice from the likes of Ross, Alpine and the other guys here who come with easy and fair solutions to the problem. While I take onboard why you would want me to do something a certain way it doesn't give you the right to your quite frankly offensive opinions.

And by the way - don't fucking tell me the platform deserves better with idealistic OS programming because this is my 4th Amiga game in 4 years and according to various sources the games have all been pretty good for the platform. The game is finished after a year for Christ sake, all I want to do is add a loading screen and here's you would have me scrap the whole thing and rewrite it.

[Thomas Richter]

Originally Posted by roondar

I already did.

"Then chances are that the alignment isn't right." is false.

That's a true statement. The alignment requirements for ECS and AGA are different, and also depend on the FMODE.

Originally Posted by roondar

And as an OS coder, you know it is false because he can't display working screens at all if the alignment it wrong (and he obviously already knows how to do that considering he released working AGA software before).

That's why graphics keeps such information.

[Thomas Richter]

Originally Posted by kamelito

I guess that if AmigaOS did provide from the start a very fast library or more for games, programmers would have used it/them but even with the latest OS release such thing doesn’t exist.

This is pretty much what the graphics library was designed to be, and pretty much the reason for its problems today as well. Lack of proper abstraction. For example, the entire GELS/vpsrite engine is nothing more than your average sprite multiplexer.

[Thomas Richter]

Originally Posted by mcgeezer

There you are again... telling me my programming and attitude is sloppy... it's not, if I was being sloppy I'd not bother making any OS calls at all and whack the system completely and use a track loader etc.

Again: If you try to render your screen with LoadView(). Well, this may work, but then do it right. I gave you the approximate sequence of calls to make it work. If you assume that pushing a copper list into a view structure and hope that this works: That's sloppy. It is sloppy because it doesn't use the interface that graphics provides for this. You make "assumptions" on how the interface work, but these assumptions are not documented, and probably wrong.



Thus, if you really want to follow this path, do it right, and read the chapter in the RKRM how LoadView() and the graphics subsystem works. It's possibly, but hairy. If not, and I understand that you don't want to follow this path, use intuition, because somebody else already did all the work for you. In a rigorous way that is known working, and providing an interface that is much easier to use.


If you believe that this "wastes memory": Frankly, please check this. For me, this is often a cheap excuse of "please don't bother, I actually do not know better".

[DMWCashy]

Thomas you clearly work on the development of the Amiga OS.
Can we not have this conversation after you make the OS functionality more optimised and usable for high end games. Then your statements would actually carry some weight.

[phx]

Originally Posted by Thomas Richter

It certainly causes a lot of problems such as: I cannot run games from the workbench, games crash with hits, games don't work with my graphics card and games don't work with my 68060. Please don't tell me, I see these problems. If things had been done properly, the software would run on the machine "as is", in the screen modes I select, and with the 68060 in place.

That's correct. I agree. And I guess that TurboSprint could have been possible on a 060 system with sufficient memory when doing it 100% OS compliant.

But many games would not exist in the same quality, especially on weaker hardware configurations. I would also say that you have a lot more trouble doing such a game with the graphics.library GELS system than by hitting the hardware directly.

Amiga coders are motivated to bring their retro hardware to the limits, which is why going through the OS is often not an option. For some of us it is also more fun to take over the system. And that's why we are here. For the fun!

EDIT: In any case you should take over the system in a clean and OS-friendly way! And it's best to never return to the OS after that. Considering that, everything should be allowed.

[DMWCashy]

Originally Posted by phx

That's correct. I agree. And I guess that TurboSprint could have been possible on a 060 system with sufficient memory when doing it 100% OS compliant.

But many games would not exist in the same quality, especially on weaker hardware configurations. I would also say that you have a lot more trouble doing such a game with the graphics.library GELS system than by hitting the hardware directly.

Amiga coders are motivated to bring their retro hardware to the limits, which is why going through the OS is often not an option. For some of us it is also more fun to take over the system. And that's why we are here. For the fun!

The day that the Amiga OS makes the hardware faster than directly accessing the hardware (HAHA) will be the day people use it for games.

[Galahad/FLT]

With the myriad of crap released on Amiga that patches system calls and can alter someone's display without the programmer of software knowing, its a bit much to expect them to work around "bug fixes" that have nothing to do with their game.

Using the system to allocate memory and file handling is fine, but if you want to ensure someone's crappy patch system cant interfere with your game, avoid the system where possible.

100% system friendly is a luxury those with fast systems can enjoy, but McGeezer wanting to cater for as many machines as possible and limit bug report to actual game bugs and not system bugs, right call

[alpine9000]

Originally Posted by Thomas Richter

Again: If you try to render your screen with LoadView(). Well, this may work, but then do it right. I gave you the approximate sequence of calls to make it work. If you assume that pushing a copper list into a view structure and hope that this works: That's sloppy. It is sloppy because it doesn't use the interface that graphics provides for this. You make "assumptions" on how the interface work, but these assumptions are not documented, and probably wrong.



Thus, if you really want to follow this path, do it right, and read the chapter in the RKRM how LoadView() and the graphics subsystem works. It's possibly, but hairy. If not, and I understand that you don't want to follow this path, use intuition, because somebody else already did all the work for you. In a rigorous way that is known working, and providing an interface that is much easier to use.


If you believe that this "wastes memory": Frankly, please check this. For me, this is often a cheap excuse of "please don't bother, I actually do not know better".

What are the pitfalls of LoadView(NULL) followed by direct hardware access?

[roondar]

Originally Posted by Thomas Richter

That's a true statement. The alignment requirements for ECS and AGA are different, and also depend on the FMODE.

It's a false statement, because McGeezer already knows how to align bitmaps and you do know this given he's released AGA software before. Worse, it rather arrogantly assumes "chances are" he'll have done it wrong without bothering to check if he actually did do it wrong.

That's why graphics keeps such information.

It's also why claiming that accomplished AGA coders likely do this wrong is rather silly.

[Thomas Richter]

Originally Posted by alpine9000

What are the pitfalls of LoadView(NULL) followed by direct hardware access?

That intuition will re-install its view again, on the next screen arrangement (C= M key, for example). Thus, LoadView(NULL) requires to wait until graphics loaded the NULL-view (one VBI), and at this point, should Forbid(). Problem is, if you now access another system function, e.g. Open(), that due to a side effect intuition comes into the play again. For example, for opening an auto requester if a volume is not available.



Thus, this is really an all-or-nothing choice.