04 February 2016, 05:43 | #21 | |
Registered User
Join Date: Dec 2013
Location: Auckland
Posts: 3,542
|
Quote:
Haha, I think I never bothered updating the Git after the initial check in.. Catacombs 3D would be interesting |
|
18 June 2016, 07:16 | #22 | |
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Quote:
Could you put the archive back into the zone? I completely missed it at the time and almost did not touch my computer for a few months so it is long gone now. |
|
20 November 2016, 22:36 | #23 |
Registered User
Join Date: May 2016
Location: Los Angeles
Posts: 67
|
Someone with the latest source, could you upload to github? That way any enhancements/changes can be easily managed.
|
20 November 2016, 22:39 | #24 |
Registered User
Join Date: Dec 2013
Location: Auckland
Posts: 3,542
|
Honestly, I made an ugly mess of things, probably not worth bothering with. It might be worth asking BSzili if he'd be kind enough to do a proper port along the lines of what he did for Catacomb 3D.
|
22 November 2016, 16:55 | #25 | |
Registered User
Join Date: Feb 2015
Location: Sweden
Age: 50
Posts: 2,948
|
Quote:
Link; http://www.ares-shop.de/product_info...c8umgitkc5t2d5 Edit: Have not seen how well the latest version runs but it uses Akiko for C2P. Skickat från min LG-H850 via Tapatalk Last edited by eXeler0; 22 November 2016 at 17:26. |
|
23 November 2016, 03:18 | #26 | |
Beta 1.666
Join Date: Jun 2007
Location: in 1985
Posts: 384
|
Quote:
Cd32 Preview- [ Show youtube player ] PC dos version as a comparison- [ Show youtube player ] No music in the Cd32 version demo! |
|
23 November 2016, 08:18 | #27 | |
Registered User
Join Date: Feb 2015
Location: Sweden
Age: 50
Posts: 2,948
|
Quote:
Skickat från min LG-H850 via Tapatalk |
|
28 November 2016, 17:48 | #28 |
old chunk of coal
Join Date: Nov 2011
Location: Hungary
Posts: 1,289
|
That's a very old video. Here's one I made:
[ Show youtube player ]
The biggest performance improvement in Catacomb 3D came from drawing the walls using 68k compiled scalers. They are basically large unrolled loops that spit out textured columns to the screen without calculating anything real-time. The original game used them for the sprites too, but it was self-modifying code which is a big no-no on 020+ with the cache enabled. Anyway, walls can be drawn at near copy-speed using this method, which would help Wolf3D too, I guess. I could give it a shot if I had the source of the latest version. |
28 November 2016, 20:54 | #29 | |
Registered User
Join Date: Feb 2015
Location: Sweden
Age: 50
Posts: 2,948
|
Quote:
Pretty sure NovaCoder uploaded the sources to aminet. :-) Is there anything that could be added without penalty? How many colors is it currently using? I just saw a proper Doom port running on a C64 with SuperCPU. They had to do some compromises but its damn impressive nevertheless. Id like to believe a decent wolf3d port on the cd32 isnt beyond reach :-) Skickat från min LG-H850 via Tapatalk |
|
30 November 2016, 16:49 | #30 |
old chunk of coal
Join Date: Nov 2011
Location: Hungary
Posts: 1,289
|
There is no concept of colors, the scalers are just copying bytes from one location to another. What I forgot about was that in Wolfenstein 3D the wall drawing is completely different, it's not done using compiled scalers. So much about that.
What would be interesting is to get a hold of the source of the Mega Drive port from gasega68k. He rewrote the whole game from scratch in assembler. |
30 November 2016, 17:15 | #31 | |
Registered User
Join Date: Feb 2015
Location: Sweden
Age: 50
Posts: 2,948
|
Quote:
"64kB RAM in he Megadrive ought to be enough for everyone? :-)" Skickat från min LG-H850 via Tapatalk Last edited by eXeler0; 30 November 2016 at 23:25. |
|
01 December 2016, 10:43 | #32 |
Registered User
Join Date: Dec 2013
Location: Auckland
Posts: 3,542
|
http://aminet.net/package/game/shoot/AWolf3D_src
Might be a good starting point (it's what I used with my aborted attempt). Switching it to use WriteChunkyPixels is easy as it already uses WritePixelArray from memory. There's a few glitches here and there (eg enemy soldiers can kill you dead from a far distance due to using UINTs for the distance calculations), it only supports Shareware edition and it's missing audio but generally seems OK. There's some ASM for wall rendering. Note that this isn't Novacoder's AmiWolf, he hasn't made his source public as far as I know. |
12 December 2016, 20:51 | #33 | ||
old chunk of coal
Join Date: Nov 2011
Location: Hungary
Posts: 1,289
|
Quote:
Quote:
One of the I things that worked well in Catacomb 3D was having most of the screen in planar. My idea is to have a double buffered native screen and convert all of the 2D graphics to planar bitmaps at load time. This way only 3D view area needs to be C2P'd into the screen. Drawing the non-3D part would be fast, and there would be no need to waste chip-RAM bandwidth by doing C2P for the full screen every frame. OK, this is interesting. Challenge accepted. Last edited by BSzili; 13 December 2016 at 21:16. |
||
14 December 2016, 01:45 | #34 | |
Registered User
Join Date: Jul 2014
Location: Shropshire / UK
Posts: 58
|
Wolf cd32
Quote:
|
|
14 December 2016, 04:34 | #35 | |
Registered User
Join Date: Dec 2013
Location: Auckland
Posts: 3,542
|
Quote:
Fantastic news can't wait. Random thing, I had this idea that maybe - assuming the guns could be rendered in 16 colours - the guns could be rendered with sprites for additional speedup, especially considering the AGA chipset supports 64 pixel wide sprites.. ..actually probably too hard, considering you'd need a contiguous block of the palette for the gun colours..*shrug* |
|
15 December 2016, 11:28 | #36 | ||
old chunk of coal
Join Date: Nov 2011
Location: Hungary
Posts: 1,289
|
Quote:
Quote:
https://github.com/earok/AkikoWolf/b.../vi_sdl.c#L172 Even if it did, blitting planar bitmaps would be faster than the generic C chunky blitter + C2P. I also thought of using sprites for the weapon, but there are too many limitations. The sprite 16-color banks are continuous, starting from a specific palette offset, that's no good. Maybe attached AGA sprites can use 256 colors? Since graphics.library has no support for AGA sprites whatsoever, I have no clue how to program them. The weapons are also upscaled from 64x64 to 128x128, so I'd need two 64x128 sprites. I'd have to keep them in memory too, which might be just too much to fit into 2MB with the rest. |
||
15 December 2016, 11:40 | #37 |
Registered User
Join Date: Dec 2013
Location: Auckland
Posts: 3,542
|
Whoops haha.. I thought for some reason I forgot to commit anything to that repository. The wl_draw.c has a few parts where only part of the screen is sent to WriteChunkyPixels (though it seems I've commented most of them out).
I don't think there's any way to make AGA sprites use 256 colours.. so far as I know the only real difference between AGA sprites and Non-AGA sprites is they can be up to 64 pixels wide, so maybe it's just a case of poking the right register? In any case I think you're right that it probably can't be used in any meaningful sense. It's a shame though.. one of the big slow downs I found with the source I was working with was simply the loop that renders the gun, I got a big speedup by just turning off guns entirely. I came up with some hack compromise where it wouldn't waste so much time just checking empty pixels to see if they needed to be rendered. |
15 December 2016, 13:43 | #38 |
old chunk of coal
Join Date: Nov 2011
Location: Hungary
Posts: 1,289
|
Sure, but setting the attached bit allows you to combine two sprites. On OCS/ECS you can combine two 4 color ones into one 16 color sprite. I would assume the same would work for 16 color AGA sprites as well, you could combine them to get 256 colors.
A less complicated solution would be converting the weapons into planar bitmap bit-plane mask pairs, and using BltMaskBitMapRastPort to draw them over the play area. It would be still faster than the brute-force method. An other solution is bringing back the compiled scalers for sprites. That would also make other scaled sprites super fast, but to do it without self-modifying code it needs much more memory. Last edited by BSzili; 15 December 2016 at 15:13. |
16 December 2016, 13:13 | #39 |
Registered User
Join Date: Dec 2013
Location: Auckland
Posts: 3,542
|
Sprites are always 4 colours (16 if attached) whether AGA or OCS. Toni's compiled a good list of the AGA specific features of sprites though I'm unsure if any of them would be any use other than the 64 pixel wide thing - http://eab.abime.net/showpost.php?p=1076544&postcount=4
In regards to the actual possibility of using sprites for the on screen weapons however: - It appears the sprite sheet for weapons is 88 colours in total (most of the frames alone use around 20-30), so either changing the palette at runtime on the copper or serious dithering would be required anyway. - *Assuming* the above could be handled in a satisfactory way (and maybe it can't be), even on maximum screen size the gun shouldn't take up than 128 horizontal pixels even when firing Gatlin on full blast. So four sprites in total (2x attached 64 pixel wide sprites) would cover it. So probably a stretch, but if it COULD be done, you'd get gun rendering with virtually zero CPU overhead. This is just for my knowledge and curiosity: - I assume a compiled scaler is essentially an unrolled loop that draws a single column of the image to the screen at a certain size? - If self modifying code can be used, it essentially allows the scaler to be generated at "real time", otherwise you'd need to generate scalers for every possible size, hence the need for much more memory? - You want to avoid self modifying code because of difficulties with CPU caching etc? |
16 December 2016, 13:54 | #40 |
old chunk of coal
Join Date: Nov 2011
Location: Hungary
Posts: 1,289
|
The biggest issue with the sprites is that they don't have separate color registers, so I'm limited to 16 consequent palette entries, which may or may not be a good match to the weapon colors. Is it even possible to change just the sprite colors? The more I think about it the more complicated it sounds.
The compiled scalers are large unrolled loops generated for a range of scale sizes (1-MAXSCALE), that draw a single column. You pick a routine for a wall height, set the texture address, the screen column and it spits out the pixels. The issue with sprites is that they can have holes in them. The original game solved this by jumping in at specific offsets, and patching in return opcodes where transparent parts begin. This won't work with the cache enabled on '020 and up. https://github.com/BSzili/refkeen/bl...3_scale.c#L750 A non-self-modifying version would need extra scalers of varying lengths, one that scales a 64, 63, 62, ..., 2, 1 pixel texture columns. I could still jump in the middle of these, but I wouldn't have to patch in the return opcore and restore it after drawing each segment. If I ever want to do port the Catacomb Adventure Series to the CD32 I'd definitely need to implement this. Last edited by BSzili; 16 December 2016 at 17:46. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
AmiWolf - new 68k Wolfenstein 3D port | NovaCoder | News | 322 | 04 August 2023 12:21 |
Unofficial CD32 port of Rally Championships | earok | Retrogaming General Discussion | 1 | 11 January 2014 03:59 |
AmiWolf - new AGA Wolfenstein 3D Port | NovaCoder | project.Amiga Game Factory | 100 | 16 September 2013 01:44 |
CD32 port 2, fire not working | skyldig | support.Hardware | 5 | 06 December 2006 17:22 |
Floppy port of the SX-32 Pro for CD32 | Tony Landais | support.Hardware | 7 | 10 April 2003 21:44 |
|
|