Page 1 of 1

A quick chat with Adisak Pochanayon

Posted: Wed Feb 26, 2014 3:11 am
by a31chris
Adisak I dont know if you seen this or not, but your work on the Jaguar version of NBA Jam TE gets some praise in this article.
Boom Shakalaka! Jam Through the Years - Video Game News - Yahoo! Video Games
Adisak Pochanayon wrote:'The most accurate version is arguably the Atari Jaguar edition, developed by The Conduit studio High Voltage Software and self-published by Atari. '

That was the project from HELL for me. 1 Programmer and 4 months to port 400,000 lines of assembler. I still have no idea to this day how I was porting 3,000 lines of production quality assembler for 4 months straight.

So you did do it in assembler like the arcade version?

I've compared them all to the arcade. Yours may well be the closest version. Saturn and PSX versions broke away from the arcade's style.

Yeah, that was a 100% asm port. We didn't have a working C compiler on the Jaguar at the time (there was an experimental GCC but it was buggy). Not to mention asm-to-C would have just taken more time. Plus I had to do all the arcade hardware emulation and a rewrite of the sound system and graphics layers.

The other versions also had very sucky slow load times... up to 30 seconds off CD. The Jaguar version was all compressed on ROM so loaded instantly and actually decompressed graphics on the fly as it drew them.
HVS a few years ago said you guys had a working C compiler for the Jags big chips that was implemented after WMCJ and eventually used C++?
Yeah, Scott Corley used C++ on Ruiner Pinball but all my work on Jag was 100% asm. I actually did a couple mostly ASM ports for PC as well - NBA Hangtime and NHL OpenIce. The main games were ported in asm but the hardware emulation layer was a combination of C and asm there.
Adisak Pochanayon @adisak may 17, 2014 wrote: fwiw the DSP code I wrote for NBA Jam was amazing. Ran audio in one context and supported full async code in the other. You could literally run two local programs (audio mixing + user code) locally on DSP.
Thanks for the chat Mr. Pochanayon. Good Luck with Mortal Kombat.

Re: A quick chat with Adisak Pochanayon

Posted: Sat May 17, 2014 8:32 am
by a31chris
More added to original interview. *bump*

Re: A quick chat with Adisak Pochanayon

Posted: Sat May 17, 2014 9:45 am
by NeoGeoNinja
This is excellent Chris! Thanks.

I'm a rather big fan of HVS's Conduit series. I thought they were a little overlooked in the big shadow of 'next gen' FPS's elsewhere.

The Conduit series took a more oldschool approach mixed with the best motion controls you'll, most probably, ever use in FPS.

The first game has a real Perfect Dark feel to it, which really works for me...

Re: A quick chat with Adisak Pochanayon

Posted: Mon May 19, 2014 12:44 am
by MegaData
I could shed some light on the C code that High Voltage had used... although I'd like to know where that information about High Voltage came from in the first place. What did they say themselves?

Re: A quick chat with Adisak Pochanayon

Posted: Mon May 19, 2014 4:27 am
by a31chris
MegaData wrote:I could shed some light on the C code that High Voltage had used... although I'd like to know where that information about High Voltage came from in the first place. What did they say themselves?
What they said themselves I quoted. They used C with the Jags graphics processor. They said its the same gcc c compiler that came with the Atari development kit.

Re: A quick chat with Adisak Pochanayon

Posted: Wed May 21, 2014 2:28 am
by MegaData
High Voltage appears to mention their own tool..."code was post processed with GCCGPUM (HVS tool)." Full text is now posted in the Programming section.

Adisak tidbits from around the net.

Posted: Wed Mar 20, 2019 4:35 am
by a31chris
Originally, I had to use Atari's music code (even though I had my own code). Atari's music code caused all sorts of bandwidth problems which involved major bandwidth hogging (two reads per cycle per channel regardless of the sample rate). In order to allow the DSP to access the bus during display, I had to drop in tons of "null" objects with the release flag set. Anyhow, the Atari music code caused major nightmarish headaches which three months of patching my code couldn't fix (yep, threw away a lot of time trying to make shit fly). Anyhow, I finally just wrote my own music code that worked and I got a 30% boost in my framerate immediately. The new music code would also allow the DSP to help perform tasks.

Unfortunately, I didn't
have time to move some of the decompression threading to the DSP which had plenty of time left over with my code running. If I had been able to use my music code from the start, WMCJ could have very well been running at 5-10 FPS faster!!!!!!! It still runs at a respectable 12-15 FPS but 17-20 FPS would have been a definite possibility.

One of the reasons why NBAJ TE runs sooooooo fast and sooooo
smooooooooth is that I didn't have to deal with any code conflicts like this.

I got complete freedom over the programming design and it really shows in how good and how quickly the project turned out.

adisak @ high voltage software

More Adisak tidbits

Posted: Wed Mar 20, 2019 4:39 am
by a31chris
The game is looking really good right now. I have optimized and optimized the game everywhere and right now it runs at about 15 fps
at a resolution of 320x220. However, this could be faster if I didn't need to unpack all the character animations on the fly but since there are 12-15 Megabytes of sprite frames, I need to keep them compressed and I unpack them immediately before they are displayed. This amounts to megabytes of compressed data being slung around which obviously
requires some additional work ;)

However, the game looks very good and has a very smooth feel to it
with the AI camera tracking the characters and all their moves. The
entire zooming thing is amazingly non-annoying (I've played games with
continuously moving cameras and most tend to make you a bit dizzy or simply detract from your ability to control the game). Finally, I
have been spending a lot of time fine-tuning gameplay.

Adisak through the years...

Posted: Wed Mar 20, 2019 4:45 am
by a31chris
I have a very simple algorithm to doom in texture mapping floors and walls in 65536 colors with light
shading to enhance depth perspective and it runs at about 40-50 frames per second!!!

I have texture mapping routines on the jaguar capable of drawing floors with depth shading and texture mapped walls at any angle which is basically a Doom graphics engine. I do not have any of the player-player interaction, collision, mapping,
etc. that Doom uses...

Adisak Adisak Adisak

Posted: Wed Mar 20, 2019 4:49 am
by a31chris
id wrote their own sound code so they could run tasks in the DSP. The Atari sound code fairly well takes over the DSP. Plus the Atari sound codes is a major drain on memory bandwidth. The music/sound driver I wrote for WMCJ and will use in NBAJ-TE uses 4:1 ADPCM compression and is over 30 times more bandwidth efficient than Atari's sound code. (on average I do 1-memory access compared to Atari's code's 32 accesses to play back a sample at 1/2 the max sample rate which is about standard sample rates). I noticed about a 15% improvement in my frame rate when i dumped their sound code for mine and an additional 10-15% improvement because I didn't have to split objects to let the DSP grab the bus more often.

Iguana 32X code conversion

Posted: Thu Nov 28, 2019 5:50 am
by a31chris
We are porting from the Iguana 32X version and making literally dozens of improvements with every step.

To be honest, WMCJ has more actual play depth than NBAJ. You have more control over the game and features like the AI in WMCJ are considerably stronger (in NBAJ-TE, the AI simply boosts computer stats and cheats when he computer gets behind). WMCJ has a much more complicated 3-D texture mapped game-field and overall is a better game IMHO. NBAJ does feature 60 fps play but only has parallax scrolling and no rendered 3-D.

Adisak pochanayon -- Jaguar Programmer for WMCJ and NBAJ-TE