tilemap.library

[Samurai_Crow]

Hello,

I was thinking about encapsulating some of the most common hardware-banging code into shared libraries so that it could be reimplemented on new hardware and guaranteed to work.

The first library I was going to do was the tilemap. I'm modelling my C source code around ScrollingTrick from the Aminet but have run into a snag: The copperlist for the vertical wraparound doesn't use RethinkDisplay(). From what I've heard, RethinkDisplay() just calls MrgCop() then places the resultant Copper-list into the control registers. I was wondering how would be the best way to implement it.

I definitely want to use RethinkDisplay() since that will allow other Copper split-screens to peacefully coexist with the tilemap screen. It will also come in handy for making multiple tile-maps on the same screen such as with dual-playfields.

What do you all think?

[Photon]

What new hardware uses split copper lists and dual playfields? Natami is getting ready? \o/

[Samurai_Crow]

Originally Posted by Photon

What new hardware uses split copper lists and dual playfields? Natami is getting ready? \o/

Hehe. No it's still in testing.

[Photon]

Well, when there is an Amiga remade in modern components there will be "another Amiga model" to code for, supporting the Amiga CPU+chipset _and more_, so it's not a bad initiative to call out for "Commodore Amiga libraries" that can then be versioned for hardware enhancements. If often thought about that kind of nice expansive yet inclusive software evolution.

About the original tilemap.library, I think it could work if the new hardware works the same way. Otherwise it's too special-purpose and a Game Construction Package with a platform deploy would allow the customization you'd want. I would not do tilemapped games with C and libs, because I still care about the A500+512k platform, and I'd like to write my own code to make it run 50Hz on that. But maybe that will change if an angel appears

[Samurai_Crow]

What I was thinking was that I could target AGA and its sub-pixel precision scrolling as the basis for the original tilemap.library and then come out with an ECS version that would just ignore the additional scrolling precision for compatibility. That would save people from having to send out to testers every time they came out with a new game. Also, an upward compatible tilemap.library could be written as a wrapper for the necessary OpenGL/Mesa libraries to ease porting to those Amiga-like platforms that don't have real Amiga chipsets any more.

As for C? I think C sucks as a language because it has such awkward pointer handling. At one time I was going to come out with an object-oriented BASIC for the Amiga and others. Now I think I'll just boost the heck out of PortablE and help Chris Handley out.

I'm not opposed to an engine with export capabilities. Mike Parent uses Multimedia Fusion 2 all the time. What I'm opposed to is requiring people to have Windows to run the editor because I don't have a Windows box to use it with.

--Update--
I've found an old Kickstart 1.2 vintage book called the Amiga Programmer's Handbook that describes MrgCop() and RethinkDisplay() with enough detail that maybe I'll be able to pull this job off!

--Update2--
The changes I would need to make would break the screen dragging code in Intuition.library so I'd be better off just building an editor that bangs the hardware anyway. Phooey. Even making an AROS driver for it would require changes to too many parts of AROS to make it possible. :-P