10 June 2018, 09:56 | #41 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,519
|
Going back in this small OT i did recently took the chance to ask Franck and Yves and have bad news: the unreal Amiga 3d engine sources have been lost
|
14 July 2018, 09:49 | #42 |
Moon 1969 = amiga 1985
Join Date: Apr 2007
Location: belgium
Age: 48
Posts: 3,913
|
|
14 July 2018, 10:56 | #43 |
Registered User
Join Date: May 2015
Location: Australia
Posts: 131
|
By the looks of these first two examples they should be possible without invoking any chunky coppers at all. At least going by the rendering just moving forward and scrolling left and right. A few games would have done this, by displaying imagery in 3d perspective and scrolling different lines, to create a 3d sideways scrolling effect.
Not proper rotation no, but effective. And using way less CPU by just programming the copper. I think copper rotation would be possible, but only with a limited size texture, and would need pre-renders along with sliding across to create full rotation effect. I would have expected by now there would have been games with actual 3d moving backgrounds. Well there are, but they are flat textures, with 2d objects above usually. I think it would be possible to have clouds roll across in 3d as well as mountains in 3d as an example. But frames would need to be pre-rendered so taking up some chip. Then the copper would be used to change frame and scroll offset so a 3d depth is maintained. Yes I'm talking about proper Amiga accelerated 3d using the copper. Taking into considerations the limitations and features of the chipset. None of copper chunky PC crap. LOL. :-P |
14 July 2018, 11:16 | #44 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,186
|
@hypex
We need to get you a Vampire stand-alone card. ;-) Once Gold3 core is out, that is.... |
14 July 2018, 16:04 | #45 | |
Registered User
Join Date: May 2015
Location: Australia
Posts: 131
|
Quote:
But then, it has that chunky plane, so is all this copper fun needed now? Indeed, can the copper affect the chunky plane? I prefer it to be called packed bitplane over chunky. :-) |
|
14 July 2018, 20:00 | #46 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,186
|
Chunky native is affected by copper on Gold 3. The problem is P96 doesn't support copper, OS3 doesn't support chunky by itself and AROS doesn't support copper. It's hardware banging season!
|
16 July 2018, 17:19 | #47 | |
Registered User
Join Date: May 2015
Location: Australia
Posts: 131
|
Quote:
OS3.1 does have some tweaking for RTG. And it is chunky aware. But the main system is still focused on bitplanes. A while back I was examining a chunky bitmap structure. They always set the depth to 1 which didn't make sense and I used to dispute that if it was 8-bits or 16-bits. Or 24. But relative to the Amiga it was correct in the sense that it was actually one bitplane. Because the pixel bits were packed across on one plane. If we compare one screen line of chunky against one line of interleaved planar in 8-bit depth both methods use 320 bytes for each line in sequence for 320 pixel width. The problem is the use of the word depth which is misleading. The depth is obviously more with an 8-bit chunky map or 16-bit frame buffer. But it describes the bitplane depth. The width isn't stored directly but only in bytes per row. An 8-bit chunky and 8-bit planar bitmap will both have 320 bytes per row in the case above so that will be set accordingly. The bitmap structure in that way was supportive of chunky or forward compatible. Bit they failed to give it any RTG flags. Nor insert a direct width in there. Now what I'd like to see is is an 8-bit planar chunky mode. That is all 8 bitplanes able to be in an extended pixel width mode, with 8-bits per pixel packed data, overlayed with their own palette if its not too much to ask! :P It is interesteing to note that HP raster data for pens can be planar or chunky. Or indeed a hybrid mode that I would have expected to be added to the Amiga. The four colour pens are sent on their own planes. So in a planar format, but each plane can be in a chunky format, a byte per colour pen index. For a direct RGB dump, it usually uses one plane, with RGB bytes sent sequentially. |
|
17 July 2018, 08:39 | #48 | |
Inviyya Dude!
Join Date: Sep 2016
Location: Amiga Island
Posts: 2,770
|
Quote:
At the moment I cannot imagine this being a working substitute for a proper tile based floor in a game like that. |
|
18 July 2018, 16:42 | #49 | |
Registered User
Join Date: May 2015
Location: Australia
Posts: 131
|
Quote:
[ Show youtube player ] Another would be Lotus. Now I don't know exactly how Lotus renders the screen but if you look at how the road is animated on screen it slides left and right with top most sliding the most as it goes into the screen or down the road. The road also moves up and down on waves so when there is a hill or a or a dip it shrinks or expands on the curve. I imagine the copper could be used to create this effect, sliding across and vertical scaling, with just a few CPU instructions to update the copperlst. Cheap 3d effect using almost no CPU time. That's what the Amiga as made for. Lotus 2 below. @ 185s. I copied the time but it doesn't work here. [ Show youtube player ] So not exactly rotation. A glorified italic line routine you could call it. But useful for when you only need to stretch it left, right, up and down. Or in this case sliding left and right or stretching up and down. About 20 years ago I was developing this technique. Or started some demo code to prove if it could work. At the time I had a bog standard A1200. I was using DPaint and used it to render a 3d road anim of about 16 frames. This was just a simple render of a road moving along. To save space I also created a simple run length compression algorithm to unpack the frames on the fly. It was called Flat IIRC. There was FlattenFile and FattenFile. LOL.The unpacking routine was written to fit inside the 010/020 cache and use fast loop mode. So my idea was for a racing game, the anim would switch every frame. And the copper would be used to slide each line across to move left or right. For up and down it would use the copper to scale the image, by skipping lines to shrink it. For a 3d bump map or wave it would have calculated where to skip lines so the effect was rendered on screen. Nice 3d road moving across and waving vertically. Now the frames would take time to unpack but leaving them in chip would save that time and leave it for other things. As I was working on it I "upgraded" to an 030. Now I don't know what happened. But the "faster" CPU wrecked my routine. On the 14Mhz 020 I had smooth motion. On the 40Mhz 030 I had stuttering. I thought it may have been a cache issue but I never figured it out. A woman entered my life, the Amiga lost popularity, and after that my project stalled and I never finished it to a working stage. Last edited by Hypex; 19 July 2018 at 08:05. |
|
19 July 2018, 17:39 | #50 | |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,281
|
Quote:
About Lotus, My idea too. To use dual playfield on A1200. One for full texture road, and use only copper to slide lines, and another for cars and other stuffs! |
|
21 July 2018, 07:02 | #51 | |
Registered User
Join Date: May 2015
Location: Australia
Posts: 131
|
Quote:
Yes what I was thinking was dual playfield. Reduces colours somewhat but copper can make up for some.And then organising the playfield between the two. So in the back layer at top have the mountains. In my elaborate case the mountains would be rendered with a few obvious frames in 3d, so when scrolling the graphic would also be changed to create a 3d mountain panning effect. Takes chip but avoids trying to create it in 2d with parallax even if copper can slide lines. This would meet with the road. Which would then be rendered in similar fashion. A pre-rendered 3d road of enough frames moving forward. Sliding left and right. Then "wave mapped" for Y position of each line. All by copper. Top layer would have clouds rendered same as mountains. Possibly sprites could also be used to render different frames of same cloud graphic at different positions on screen giving way to plot clouds using same cloud from different 3d scrolling pans. But essentially 3d clouds panning across. Below this the main action. Trees or other barriers. Cars. The Trees would be pre-renders with 3d panning. But scaled onto screen in realtime, unless a 3d panned in different scales was small enough. Likely using blitter. This would create illusion real 3d depth in trees and other objects. The cars, depending on complexity and time, maybe 3d rendered in realtime as a CLUT and then written to screen in planar. Would most likely adopt same technique as trees, so cars would have proper 3d depth, as they move left and right. And going into screen. For score panel sprites could be used or a top playfield layer. Could also use sprites for other objects on screen. Parallax layers could be exchanged when and where needed for ease of rendering. Also have idea in mind for fighting game. Would not need so much action so floor could be static. CPU time could be spent 3d rendering characters. Sprites for superimposing images on screen. Also have idea for 24-bit colour sprites where palette is changed each line before that sprite line appears on screen. Using 15-colour sprites as base object. Taking into account colour clashes and other conflicts. |
|
22 July 2018, 21:19 | #52 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
After all, not all driving/road-based games need a lot of colors and the graphics can be made sci-fi or simplified to fit with a reduced number of colors as part of a dedicated art style. |
|
22 July 2018, 22:43 | #53 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,186
|
On AGA don't forget that you can bank switch all 16 colors in one Copper move thus allowing double buffering of palette changes every row of pixels so you can easily use the visible area of the screen for more palette changes.
|
23 July 2018, 09:39 | #54 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
If the hardware is designed to update a "pointer" to the current CLUT when switching banks rather than copying the selected CLUT to the current one then mid-line palette switches should be instant and could be very useful. |
|
23 July 2018, 10:54 | #55 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,186
|
I don't know how often the bank select register updates. If I were designing the chip I'd make it latch in at the end of a line only.
|
23 July 2018, 11:33 | #56 |
Registered User
Join Date: Jun 2016
Location: UK
Posts: 428
|
|
23 July 2018, 12:48 | #57 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,186
|
|
23 July 2018, 13:03 | #58 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,505
|
Bitplane color bank select (8 banks of 32 colors) only affect color register writes, it does not affect output. Sprites have output bank selection registers (16 banks of 16 colors, one for odd and even sprites)
BPLCON4 8 XOR bits are probably what you meant and it has extra 1 hires pixel delay compared to normal color palette register writes. I am not sure if sprite bank selection has same delay. |
23 July 2018, 13:19 | #59 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
BPLCON4's XORing mechanism is more appropriate than the register bank switching indeed. This is great news, and means that whole palette changes can be simulated almost anywhere. This would be a great way to add colors to dual playfield games for example. Thanks for the clarification Toni! |
|
25 July 2018, 18:54 | #60 | |
Registered User
Join Date: Feb 2011
Location: Italy/Rome
Posts: 2,281
|
Quote:
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
What are "VGA mode resolution autoswitch" and "Variable sync"? | Foebane | support.WinUAE | 2 | 09 November 2017 21:21 |
Keep Active control panel "Line Mode" and "Interlaced Line Mode" | Zilog | request.UAE Wishlist | 4 | 02 August 2014 23:08 |
Looking for a "Gauntlet" style game | SilverHand | Looking for a game name ? | 7 | 21 January 2005 19:05 |
Looking for a "Wild West" - style, game name... | Shoonay | Looking for a game name ? | 3 | 21 October 2004 23:25 |
|
|