Messages

1

Programming / Re: opl emulation for music

« on: April 07, 2011, 09:19:57 pm »

I took that section you have highlighted (minus the name of course) and copied it to a bunch of different files with every file extension that adplug supports. Then I tried to load them into foobar2000 with adplug, and none of them would play. It seems that we're dealing with an unknown format.

2

Programming / Re: opl emulation for music

« on: April 07, 2011, 08:43:23 pm »

The *INTRO.CAT files are just sound effects if I'm not mistaken.

Bleh. It's a 1.2 thing, from ufopaedia: "DOS 1.2 - for some reason music for intro is stored in separate file"

aintro.cat is adlib, rintro.cat is roland, intro.cat is sound data.

Anyway if your compare the section you highlighted with what I was looking at in aintro.cat, the format looks the same, both start with 5A 09, the data looks a bit different tho.

3

Programming / opl emulation for music

« on: April 07, 2011, 01:53:42 am »

I've been looking into whether we can get opl2/adlib music going, unfortunately I think I've hit my limit. I started with the information that fraggle provided about putting OPL emulation into chocolate doom:

https://www.chocolate-doom.org/wiki/index.php/Opl-branch

One of the main things he did was produce a DRO (Dosbox Raw OPL) file from dosbox to analyze how the original doom executable wrote to the OPL registers.

So I ran dosbox and captured some OPL from the intro music, and then compared what I was looking at in the hex editor to the files stored in AINTRO.CAT, and I am completely baffled by the file format inside AINTRO.CAT.

The DRO format is well documented:

https://www.shikadi.net/moddingwiki/DRO_Format

And the CAT format is understood, but it is the adlib data files stored inside the CAT that aren't making any sense right now.

The DRO:


The first file stored in AINTRO.CAT:


If I was way better at assembly language I would start tracing how the DOS program is interpreting aintro.cat but my skills are weak

4

Programming / Re: aspect ratio correction

« on: July 31, 2010, 08:57:03 pm »

And I'm not sure X-Com was designed for 4:3 anyways

All DOS games of this era did 320x200 on a 4:3 monitor, so each pixel was 1 unit wide and 1.2 units tall. If the Amiga version was different, I don't know, but the psx port came later

5

Programming / Re: aspect ratio correction

« on: July 29, 2010, 08:55:57 pm »

Simple 2x scale:

2x scale, aspect corrected:

Simple 2x scale:

2x scale, aspect corrected:

6

Programming / aspect ratio correction

« on: July 29, 2010, 07:34:13 pm »

this is some pretty terrible code that adds a new parameter to the setScale method of the Screen class. it uses some hardcoded values so is probably not suitable for trunk

for reference: https://doom.wikia.com/wiki/Aspect_ratio

7

Programming / Re: [Solved] Textures

« on: July 22, 2010, 08:21:08 pm »

Gotta love a library bug, good job spotting that one pmprog

8

Programming / Re: [TASK] Converting cartesian coordinates to polar coordinates

« on: June 18, 2010, 06:31:48 pm »

So... anyone have any ideas how to solve this?

I've thought about this before and I'm not sure if my idea is going to make any sense after typing it out, but here goes:

The geoscape screen is always going to be 320x200, and you already (obviously) have done the math to project the globe into screen coordinates. What I am thinking is do a projection with (0,0,0) rotation and then save a "mapping" of which lat/long gets drawn at each location in the 320x200 screen space. Then when the mouse interacts with it, you have the latitude and longitude as if the globe were at (0,0,0) and you can "rotate" the mouse click based on how the globe is being displayed.

Actually if you update the mapping every frame that you display then you don't even have to "rotate" the lat/long you get from the mouse interaction

edit: ummm I just read your OP again and are you converting to a sphere before you do any drawing? because maybe you can build the map i've described by doing the polar coordinate -> sphere -> screen pixel calculation for each pixel with a test program and then just make the mapping a struct

edit: haha I just read someone elses solution to your polygon problem and that solution is similar.. store meta-info for screen coords

9

Open Feedback / Re: Fullscreen?

« on: June 17, 2010, 09:59:35 pm »

Chocolate Doom probably has some good GPL code for scaling 320x200 to modern resolutions via SDL.

10

Open Feedback / SVN path

« on: June 17, 2010, 09:57:07 pm »

I think the svn path in the "compiling" section of the website is incorrect, it is:

https:https://openxcom.svn.sourceforge.net/svnroot/trunk/

The correct path seems to be:

https:https://openxcom.svn.sourceforge.net/svnroot/openxcom

I was going to email about it but could not find an address, sorry