English Amiga Board


Go Back   English Amiga Board > Other Projects > project.CD32 Conversion

 
 
Thread Tools
Old 16 December 2016, 17:51   #41
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,422
Quote:
Originally Posted by BSzili View Post
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.
NOT a coder but as a graphics guy I have vague memories about setting palette start offsets for sprite usage. So unless Im way out of line here, couldn't you reserve part of a fixed 8 bit palette for 2d graphics and set a different offset palette start for the various weapons?
(Seems to me Wolfenstein has very little actual palette variation.)



Skickat från min LG-H850 via Tapatalk
eXeler0 is offline  
AdSense AdSense  
Old 16 December 2016, 18:41   #42
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 220
Send a message via MSN to BSzili
Reserving 16 colors for sprites is the only clean way to do it, the first row with the standard 16 color PC palette looks a prime candidate for that:
http://diehardwolfers.areyep.com/bun....htm#appendixb
There might be some graphics using them, or they could have some special function. In that case remapping is necessary, which would complicates things a bit, especially for sprites. Anyway this is a bit too early, first I need an example C program on how to do AGA sprites.
BSzili is offline  
Old 17 December 2016, 17:53   #43
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 919
Send a message via Yahoo to Samurai_Crow
If you can squeeze 15 colors per row of pixels and allocate 2 banks of 15, you can double buffer the sprite palette with the Copper list.
Samurai_Crow is offline  
Old 17 December 2016, 18:53   #44
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 220
Send a message via MSN to BSzili
Ok, I more or less have a clean base to work with. I have two Intuition screen buffers, latched images are drawn with BltBitMap, the fonts are drawn with BltTemplate. I have a continuous chunky buffer converted directly with Akiko with the starting offsets and pitch precalculated.
Now the quest to find fast drawing routines for the 3D portion (walls, sprites, weapon) starts. I gave the original sources another look, and I was wrong, it still uses compiled scalers. In fact it looks quite similar to what was in Catacomb 3D with some extra compacting for the table. First I'll check if I can reuse the code from Catacomb 3D.

edit: Compiled scalers for the walls work now, this is a good start. Wall scaling now works at copy-speed, I got a 50% speed increase from 3 FPS to 6 FPS The huge AsmRefresh function eats up a lot of CPU time. In the original game it was in assembly, hence the name, and for a good reason.

Last edited by BSzili; 17 December 2016 at 20:26.
BSzili is offline  
Old 17 December 2016, 23:28   #45
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,422
Quote:
Originally Posted by BSzili View Post
Ok, I more or less have a clean base to work with. I have two Intuition screen buffers, latched images are drawn with BltBitMap, the fonts are drawn with BltTemplate. I have a continuous chunky buffer converted directly with Akiko with the starting offsets and pitch precalculated.
Now the quest to find fast drawing routines for the 3D portion (walls, sprites, weapon) starts. I gave the original sources another look, and I was wrong, it still uses compiled scalers. In fact it looks quite similar to what was in Catacomb 3D with some extra compacting for the table. First I'll check if I can reuse the code from Catacomb 3D.

edit: Compiled scalers for the walls work now, this is a good start. Wall scaling now works at copy-speed, I got a 50% speed increase from 3 FPS to 6 FPS The huge AsmRefresh function eats up a lot of CPU time. In the original game it was in assembly, hence the name, and for a good reason.
Interesting..
Do you have a target fps towards which youll optimize against or just make it as fast as you can and see what you end up with, so to speak?

Skickat från min LG-H850 via Tapatalk
eXeler0 is offline  
Old 18 December 2016, 12:28   #46
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 220
Send a message via MSN to BSzili
I think 12-15 FPS would be the minimum for this type of game to be playable, the Mega Drive version is in that range. How to get there is anybody's guess, I'll start with stripping down the AsmRefresh function to see what makes it so slow.
BSzili is offline  
Old 19 December 2016, 22:11   #47
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 220
Send a message via MSN to BSzili
I tried cleaning up the function, I even looked up an older C version which is as lightweight as it gets. It's no good, it's still dog slow, I only got a couple FPS with the actual drawing dummied out.
The SNES and Mac version of the game used BSP trees instead of ray casting, which is said to be faster. Fortunately the Mac version is open source, I'll have a look at how it works.
BSzili is offline  
Old 19 December 2016, 22:30   #48
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,422
Come on man you can do it, look :-)

http://mashable.com/2016/12/19/wolfe...2#LXT1dcDNCqqs

Edit: (Kind of cheating with a custom CPU in the cartridge, but still ;-)
eXeler0 is offline  
Old 19 December 2016, 23:59   #49
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 220
Send a message via MSN to BSzili
Yes, I can reduce the view area to ~160x90 too.
BSzili is offline  
Old 20 December 2016, 00:09   #50
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,422
Quote:
Originally Posted by BSzili View Post
Yes, I can reduce the view area to ~160x90 too.
That was actually what I was wondering in post #45 , I think shrinking the view area is a legitimate path to achieving playable frame rates if all else fails. ;-)

Skickat från min LG-H850 via Tapatalk
eXeler0 is offline  
Old 20 December 2016, 00:49   #51
Akira
Registered User

Akira's Avatar
 
Join Date: May 2001
Location: New York
Posts: 18,301
I think the other trick we can take from that is that the game skips lines to be rendered. Can you draw every two? might look weird on a CRT, but we can try, right?
Akira is offline  
Old 20 December 2016, 01:25   #52
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 220
Send a message via MSN to BSzili
Skipping lines in this case wouldn't help since drawing the individual columns is fast, but the horizontal resolution could be halved so the raycaster has less work. Still, it bothers the heck out of me that the raycaster is this slow. I really want to try BSP trees, but I don't have a node builder or the original SNES/Mac levels for that matter.
BSzili is offline  
Old 20 December 2016, 07:14   #53
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 919
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by BSzili View Post
Yes, I can reduce the view area to ~160x90 too.
If you're going that low, you might as well use Copper Chunky.
Samurai_Crow is offline  
Old 20 December 2016, 10:45   #54
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,422
Quote:
Originally Posted by Samurai_Crow View Post
If you're going that low, you might as well use Copper Chunky.
He said that of course only because as a comparison to the rather puny Gameboy Color resolution :-), but.. yes... As long as we are dealing with the crippled Amigas (i.e. 020 without fast RAM) maybe Copper chunky is the fair enough "Amiga chipset limitation" -way of doing it.
The AKIKO chip never gave more than... what... 25% boost for C2P?

From some old forum post I have these numbers for AGA Copper chunky: 330×256 in (3×2pixel mode)
or 220x256 in (2×2)

I think 220x256 (2×2 pix) sounds acceptable?


Skickat från min LG-H850 via Tapatalk
eXeler0 is offline  
Old 20 December 2016, 10:54   #55
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 919
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by eXeler0 View Post
He said that of course only because as a comparison to the rather puny Gameboy Color resolution :-), but.. yes... As long as we are dealing with the crippled Amigas (i.e. 020 without fast RAM) maybe Copper chunky is the fair enough "Amiga chipset limitation" -way of doing it.
The AKIKO chip never gave more than... what... 25% boost for C2P?

From some old forum post I have these numbers for AGA Copper chunky: 330×256 in (3×2pixel mode)
or 220x256 in (2×2)

I think 220x256 (2×2 pix) sounds acceptable?


Skickat från min LG-H850 via Tapatalk
Sorry, I missed the GameBoy reference. :-)

As for the resolution of non-overscanned Copper Chunky on AGA, the resolution is 160x256 PAL or 160x200 NTSC. I would not suggest doing the bottom panel in Copper Chunky though. Also, if you don't do horizontal overscan, the sprites remain active so you don't need to redraw the hands holding the gun and the palette registers used by the sprites remain completely available.
Samurai_Crow is offline  
Old 20 December 2016, 11:02   #56
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 220
Send a message via MSN to BSzili
I was sarcastic. He sent me a video of a custom written version running on a custom hardware in a tiny, tiny screen. The C2P is as good as it gets, I need fast rendering for the walls.
BSzili is offline  
Old 20 December 2016, 11:20   #57
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 919
Send a message via Yahoo to Samurai_Crow
Ok. I get it now. Unfortunately, the Wolfenstein level editor I saw back in the day shows the levels being stored as tile maps.

Will this help? http://www.afadoomer.com/wolf3d/about.html

Last edited by Samurai_Crow; 20 December 2016 at 11:32. Reason: added link
Samurai_Crow is offline  
Old 20 December 2016, 11:42   #58
eXeler0
Registered User

eXeler0's Avatar
 
Join Date: Feb 2015
Location: Sweden
Age: 43
Posts: 1,422
Quote:
Originally Posted by BSzili View Post
I was sarcastic. He sent me a video of a custom written version running on a custom hardware in a tiny, tiny screen. The C2P is as good as it gets, I need fast rendering for the walls.
You definitely shouldn't see it as a "taunt" but rather as inspiration - that there are other retro enthusiast out there trying to do stuff that has never been done before for no other reason than to prove a point, or "because why not" :-) (like the dude that got Doom running on an HP printer :-)
I want to cheer you on in your efforts!


Skickat från min LG-H850 via Tapatalk
eXeler0 is offline  
Old 20 December 2016, 12:49   #59
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 220
Send a message via MSN to BSzili
Don't worry, I wasn't put off by it. In the meantime I found the source code of WolfEdit 2 for Mac, which has a node builder. It's in Pascal, so I either translate it to C so I can include it in the game, or touch it up for FreePascal keep it as a separate utility. We'll see.
BSzili is offline  
Old 31 December 2016, 22:01   #60
BSzili
Registered User

BSzili's Avatar
 
Join Date: Nov 2011
Location: Hungary
Posts: 220
Send a message via MSN to BSzili
I managed to write a mostly working node builder based on WolfEdit2. It was a good idea to rewrite it, the level format of the DOS version differs quite a bit.
The pushwalls are going to cause some trouble because the console/Mac version has simplified levels, where only one pushwall side is visible to the player. The original DOS version on the other hand has levels where you can see up to 3 sides, some has two pushwalls next to each other, etc.
Then came the horrors, the DOS version of Wolf3D still uses degrees for its angles. The bsp renderer needs to calculate many angles, so before I can do anything I have to switch to BAMS.
What have I got myself into...
BSzili is offline  
AdSense AdSense  
 


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 265 17 December 2016 05:05
Unofficial CD32 port of Rally Championships earok Retrogaming General Discussion 1 11 January 2014 04:59
AmiWolf - new AGA Wolfenstein 3D Port NovaCoder project.Amiga Game Factory 100 16 September 2013 02:44
CD32 port 2, fire not working skyldig support.Hardware 5 06 December 2006 18:22
Floppy port of the SX-32 Pro for CD32 Tony Landais support.Hardware 7 10 April 2003 22:44

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:21.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.45444 seconds with 13 queries