Porting ProQuake To Flash in the blink of an eye

[Baker]

I'm going to build a Flash ProQuake in 3 hours or less if nothing goes wrong.

Why do this?

First, because it is there. Second, I bought a PSP 1000 series and FlashQuake uses Cygwin for the compile so it'll be a fun exercise to prepare for when my PSP arrives probably next week. Third, the greater ProQuake 4 functionality will be fun to get a better feel for FlashQuake's performance because I can do things like pq_drawfps 1 and see the framerate.

Note to self:

Future ideas: Port FTEQW's 24 bit color software renderer to ProQuake? I'd like to see Half-Life maps running in Flash and I think FTEQW's software render might support alpha transparency.

Port CSQC to Flash? Don't know if this is possible, but if it is possible I will be doing this with all the other engines.

Planning Stage
--------------------
I've identified the differences in Flash here. Nothing scary. As far as I can tell.

Describing all the changes in FlashQuake.

Not covering system, input or network differences (there is no network support). Largely because those aren't changed files but "new" files. For my purposes here, I care only about changed files.

1. menu.c

a. "Saves" the config.cfg every time upon exiting menu. Saves as a flash cookie or something to that effect, since no true filesystem access.
b. Video modes effectively is IFDEF'd out.
c. Save games file system using as3

2. r_main.c

a. No use of *r_stack_start; Three changes.

3. host_cmd.c and host.c and cmd.c

a. Minor file system changes using as3objects i/o

4. pr_cmds.c, cl_tent.c

a. Use of myAtan2 for pitch and yaw

5. cl_parse.c - No use of VID_HandlePause

6. draw.c

Code: Select all

void Draw_BeginDisc (void)
{
   if(!draw_disc)
      return;   //On Windows you can get away without checking for null, because D_BeginDirectRect checks vid_initialized. But not for FLASH

   D_BeginDirectRect (vid.width - 24, 0, draw_disc->data, 24, 24);
}

7. quakedef.h

a. Flash "file system" definitions (as3 objects)
b. myAtan2 "//For Flash, we need to swap round the arguments for atan2" (Baker: weird! Can't use a C math function the normal way? Ok then ...)
c. NO_ASM

8. screen.c

a. Don't use SCR_ModalMessage ... apparently Flash can't get the input in the manner required. Coded to always assume someone said yes.

9. console.c

Echos all the console messages to the Flash debug console

Code: Select all

void Con_Print (char *txt)
{
   int      y;
   int      c, l;
   static int   cr;
   int      mask;

#ifdef FLASH
   {
      AS3_Val as3Str = AS3_String(txt);
      AS3_Trace(as3Str);
      AS3_Release(as3Str);
   }
#endif

11. Sound changes. FlashQuake isn't coded to support volume control (I wonder if this can be done) and additional changes to get Flash to play sounds.

General note: Traditional #IFDEF _WIN32 will be true in Cygwin even though you aren't compiling for that platform. So most of these need to be become #IF defined(_WIN32) && !defined(FLASH)

[Baker]

Stage Zero

Rename all files with better names:

snd_null.c -> snd_flash.c
sys_null.c -> sys_flash.c
vid_null.c -> vid_flash.c
in_null.c -> in_flash.c

screen.c -> r_screen.c
world.c -> sv_world.c
r_draw.c -> r_rast.c
draw.c -> r_draw.c
view.c -> cl_view.c
model.c -> r_model.c

Modify make file and compile.

[Baker]

Stage One

After messing around with countless small differences and compiler complaints and small weirdnesses of all sorts, I got it to compile.

I am annoyed it took 4 hours. I was shooting for 3 hours.

One things that speeds up porting ProQuake is that half the features can be instantly disabled by precompiler directives, which I have since I have so many builds (d3d, gl, win, osx, linux, osx software, dx8) which allows me to flip operating system specific features off quickly.

Will it run? Hmmm. My guess is not the first time, there is always something.

[Baker]

It didn't run, but the more surprising thing is that it didn't run with a situation that MSVC6 wouldn't allow to happen upon compile, the missing symbol.

Not used to something compiling with that situation existing.

I'm not sure if Adobe Alchemy is allowing that or if it is gcc that permits that (I'm thinking not).

I think I have 3 or 4 of these situations. Either way I'll have to wrap this up in a few hours because I don't have time to continue right now.

[Downsider]

Porting JoeQuake in a "Flash"

[Baker]

Built and running with a couple of weirdnesses.

http://www.quake-1.com/docs/flashquake/ ... Source.rar

[Baker]

I just wanted to learn about the limits and capabilities of Adobe Alchemy and Flash concerning Michael Rennie's Flash Quake port.

Flash ProQuake 4.00
Download: Flash swf | Source code

Features software ProQuake has above and beyond WinQuake without a network connection:

1. 32 MB RAM allocation instead of 8 MB.
2. A particular chasecam fix for WinQuake
3. Demo fast forward and rewind using PGUP and PGDN
4. cvarlist and cmdlist commands
5. r_viewmodeloffset (gun shifting)
6. WinQuake and DarkPlaces looking gun placement
7. pq_maxfps to cap frames per second
8. pq_drawfps 1 to show the current FPS
9. Advanced Preferences menu
10. Raised max_edicts
11. centerprint logging (like FitzQuake)
12. Anti-wallhack sv_cullentities 1
13. hunk_print command
14. time command
15. viewpos and other commands
16. writeconfig
17. Other miscellaneous bug fixes.

Observations

a. The "time" command prints 5 hours ahead of me, so apparently Flash's access to the system clock doesn't know the timezone.
b. I believe I read that Flash operates at 24 frames per second. There isn't a way to increase that it would seem.
c. The current FlashQuake doesn't have volume control, but I did notice that the sounds correct fade in the distance so I think I can eventually enable sound control via volume.
d. Apparently increasing the memory allocation from 8MB to 32MB isn't causing Flash grief. If you think of Flash as a virtual machine, other than lack of network this isn't that bad.
e. The saved config.cfg isn't available locally from session to session. Supposedly this is a feature of FlashQuake according to Michael Rennie.
f. Flash didn't mind doing the sv_cullentities 1 thing, which is enabled by default in ProQuake.

I'm going to maintain this build as part of future ProQuake 4 releases simply because it is easy to maintain --- no more work than the OS X build. Despite the lack of immediately obvious uses for FlashQuake beyond a candidate for an SDA demos viewer or the novelty of being able to use Quake via Flash, it is a very well built port.

I haven't dug into Spike's CSQC modification to see if network changes are involved, but there may be nothing preventing CSQC finding it's way into this. And regardless of whether or not the FlashQuake currently or will ever have a practical use, this was a great alternate "operating system" test port of ProQuake. I had to disable and rework a few things here and there, like for Linux and OS X.

If improved mouselook could be made for this, it would be a better port. One barrier is that WinQuake and GLQuake snag the mousepointer and continually force to the middle of the Quake window as a "hack" when DirectInput is not being used. Flash cannot do this.

Future upgrade ideas:

1. FTEQW 24 bit color software renderer
2. Exploring better mouse look
3. Sound
4. Ability to use data files outside the self-contained Flash
5. Seeing about Flash cookies to store the config.
6. Map menu

[Baker]

Ended up updating the above with working volume control.

In ProQuake 4, -/+ adjusts the volume. FlashQuake didn't have working volume control.

Looking at snd_mix.c, apparently the non id386 (non-Intel 386 processor) code actually doesn't use the volume cvar for anything (weird!).

I modified SND_PaintChannelFrom8 as such to give it volume control:

Code: Select all

#ifdef FLASH
   {
      int         templeft, tempright;
      templeft = (int) (ch->leftvol * volume.value);
      tempright = (int) (ch->rightvol * volume.value);
      templeft = bound(0, templeft, 255);
      tempright = bound(0, tempright, 255);
   
      lscale = snd_scaletable[templeft >> 3];
      rscale = snd_scaletable[tempright >> 3];
   }
#else
   lscale = snd_scaletable[ch->leftvol >> 3];
   rscale = snd_scaletable[ch->rightvol >> 3];
#endif

Source and the flash.swf in the above post have been re-uploaded.

[Baker]

A much better Flash ProQuake in the mouse control sense of the matter. Added Rennie's improvements (sound lag removal).

http://www.quake-1.com/docs/flashquake/ ... 400_v2.swf

Source: http://www.quake-1.com/docs/flashquake/ ... v2_src.rar

Probably the best way to further improve the mouse look is to completely remove the FlashQuake mouse1 behavior and let toggle console "release" the mouse --- which since FlashQuake can get ahold of the mousepointer like other engines can -- just means make it visible. Then see about making mouse1 a standard bindable command. (Some interesting notes I found about ASNative .. which may make binding at least mouse 3 possible?)

[Teiman]

Niiiice.

[Baker]

Update in-progress ...

[gnounc]

very nice, great that I dont have to hold down the mouse button

as soon as left and right click work without unfocusing the game, it will be perfect.

I'm impressed

[Baker]

Note mostly for self:

in_null.c
snd_dma.c
snd_mix.c
sys_null.c
Main.as
Preloader.as

These files were the ones that Rennie changed to get rid of the sound delay.

[Baker]

Extra notes ...

1. Add support for a file called something like quake.cmdline like the PSP has. This will help dealing with command line.

2. Add support for the -nomouse command line parameter.

3. Check in_flash.c and make sure pq_fullpitch cvar is in effect there.

4. See if any bots mods work with this (to investigate someone's report that they couldn't get bots to work with it). Especially, check sv_progs.dat capability. The way FlashQuake is setup, multiple gamedirs would not be very feasible, but sv_progs is an easy solution to solve that in a lot of ways.

[Baker]

Confirmed: FlashQuake doesn't like bots very much.