Real Flash Quake

[MadGypsy]

My favorite language is still AS3. I think HaXe is pretty bad-ass but, AS3 primed me for all the scripting languages that I know. I remember when I first picked up PHP it was really really easy because a whole lot of it is very similar to AS3 syntactically. It becomes very different in other ways like built-ins and APIs but syntactically they are cousins or something. AS3 was the first class/interface/abstract capable language that I ever learned. I learned design patterns through an 800 page book entitled (something like) Design Patterns in AS3. About 10/12 years ago I completely redirected myself from a drinking problem with AS3. I have so much history with this language it is unreal. I started when it was just called Actionscript (AS1)...about 16 years ago.

@really though I just find weakly-typed languages annoying.

Neither Haxe nor AS3 are weakly typed. In the case of AS3 the closest you will come to weekly typed is :* but, that's a liar symbol cause you are still typing as bject. In haxe you can weakly type and sometimes you even want to. It uses type inference and sometimes that shit seriously matters. Here is an example of why:

var writer = new format.io.Writer();

BUT in format.io.writer at the very top is a compiler condition

package #if haxeversion > 3 haxe.io #else format.io #end

if I typed writer to format.io.Writer AND I was using a haxe version > 3...we would have some problems. However, through type inference, writer will get properly typed to whatever format.io.Writer returns. It's like it strong/strict types for you.

I understand what you are saying though. I'm sort of opposite. I like the strong typing a lot but, I also like the freedom of the sloppier languages. Javascript, to me, is like a PoC language. You write some slop to get the general idea down and then bring that flow to something worth scripting in and port it, advance it.

[MadGypsy]

@me wants to see MadGypsy write some toy operating system... Target qemu or something.

I mean, I'm definitely swamped for now with my engine but, I did look at qemu for a minute and I bookmarked it. Maybe it will come in handy if I ever decide to make a device. I've always wanted to go all the way like that but, I don't think Imma live long enough.

edit: I don't think I'm dieing or anything. I'm just super duper slow. I spend a lot of time breaking pretty good things to make them at least potentially better. I'd be a lot faster if I stopped doing that. I'd also have stuff that isn't as good as what I have. My stuff is pretty good. My RAM and FPS's told me so.

[MadGypsy]

Man, I wrote this bad-ass content manager/file loader in Haxe for my game engine. It was actually an elaboration of a similar but, far less capable file handler that I wrote for flash. It can handle (haxe version) all of your most common file types and it can also handle all of that from within a zip or lzma zip. I even have an abstraction layer that handles the formatting of these file types to flash expectations. For instance PNG, JPG, BMP as far as flash is concerned all of that is 24 or 32 bit BitmapData, and by flash I mean HaXe too, well, Haxe w/ OpenFl anyway.

I'm digressing. I wanted to port my HaXe version over to pure AS3 (ie actual flash). Hoo hoo hoooooo boy is it a mother fucker. Ive just spent the last few months working with typedefs and type inheritance through extension (ie var somevar:AbstractIdea = new ConcreteIdea()).

In flash there are no typedefs so...that's completely out the window for that method but, that's small beans in comparison to the other issue. I have to go write interfaces for the whole back end of the file handler or there wont be any ConcreteIdeas instantiated from an AbstractIdea type.

Unless I want to treat everything like * there is NO way around this. In haxe the ultimate super doesn't have to implement an interface to be considered a base type. This is gonna take a minute...and by minute I mean I might not even finish today. Tomorrow for sure though.

I could totally cheat and just go grab the flash port of my code from haxe. I'd rather not. HaXe might write all the code for you but, it's really fucked up code...and by fucked up I mean, the computer that wrote it doesn't need nice readable names, nesting, etc... It's like reading a min.js except far far worse.

[MadGypsy]

You might be able to make trivial changes to the source, but you couldn't program in it (at least not any time soon).

With low-level languages, you are closely exposed to the machine level:
* Bit order
* The storage of data in byte form (endianness, internal representation of floating like IEEE 754)
* Implications of unsigned types
* Direct memory allocation and deallocation
* Direct memory access
* The mechanics the call stack
* Word size occasionally
* Choices when it comes to handling of "string" data
* Padding and how that works
* The implications of loop unrolls and other optimizations a compiler may use
* Manual "construction" and "deconstruction"
* System messages
* Signals
* Automatic variables and the differences in their interactions
* The myth of the "constant variable"

Not all languages are the same.

The low-level ones give you more control, with more control requires a deeper understanding.

It becomes second nature at some point and you no longer need to actively think about the mechanics.

I said I could program in it and that's all there is to it. Half of what you said I already know and the other half is exampled throughout the quake source. You love to try and tell me what I can and should do but, it never has any bearing in what I can and will do.

[Baker]

Half of what you said I already know and the other half is exampled throughout the quake source. You love to try and tell me what I can and should do but, it never has any bearing in what I can and will do.

You tend to ...
1) Under-estimate the difficulty of everything
2) Over-estimate what you know

That's why when you successfully made a BSP renderer ...

It was like watching a guy being stung by a million hornets and keep trucking. And then get stung by a million more hornets.

I admire that determination. That's what it takes to learn.

/Just remember you thought it would take a week to make a BSP renderer.

[MadGypsy]

Instead of arguing I will approach this differently.

fact 1: learning a language for me has nothing to do with learning how to program.
fact 2: learning syntax is instaneous for me. I have too many languages under my belt to get tripped up on a flipped around signature or an unclear symbol

That means all of my learning time is spent learning Intracacies. Any language.. ANY language, 3 months absolute tops. And it never takes me that long. C languages I admit are more involved but, when you already understand the fundamentals those other involvements are not all that complicated.


@bsp parser
yep, we all start somewhere. Wait til you see where I am now though. Personally, I percieve most quake engine sources to be shit code. The entire engine is treated as one big spaghetti package. You don't have to know anything about a quake engine to modify my source. It is heavily organized and everything does what it is named and nothing more or less. I could give you numerous examples straight out of just about any source where there's a "while we're here" mentality. That's total junk and makes figuring out the scope a nightmare. Also, quake sources (most) don't seem very extendable. You could subclass my entire engine and extend it's capability. Then and now, bro. I started off falling on my face every step and now I'm running. I always know what I'm doing even if it seems like I never will.

Those who dare to fail miserably can achieve greatly.

[MadGypsy]

Last night I added a shout/ice cast player to my engine. It currently has no UI and is hard-coded to play the Secret Agent Music stream from SOMAFM but, I will develop this as time goes on.

Oh, also, after I ported my content manager to AS3, I decided to port all of my haxe engine to AS3. That is almost complete and now I need to port a shout/ice cast player over to haxe. I like this. It keeps things fresh. I'm going to keep doing it this way. Plus, I found 3 mistakes when porting haxe to flash. I fixed those mistakes in both versions. That's awesome cause, one of those mistakes I couldn't figure out in Haxe but, when I ported the mistake to flash it was a serious "oooooooooh" moment.

In the near future I am going to port my shout/ice cast player to c++. I'm going to make that my first c++ project. It only takes 4 classes to instantiate an ice/shout cast stream in flash. Even if it's double that in c++, whoopee doo. I pretty much just want to put it to bed once and for all that if I say I can do something, that means I can do it and that's all there is to it.

Here is my wicked simple implementation of playing a stream. This is powered by 4 classes but, these 2 lines are all it ever takes to get a stream going. No buffer overflows or connection errors. The same stream has been playing since 11pm last night...17 hours. I think it's safe to assume it's stable.

Edit: for the record - I have all the event listeners programmed in for various connection and stream states. My engine's implementation actually taps all that and decides what to do accordingly but, these 2 lines are all it takes to get the music going as long as there is not one issue (there generally wont be).

[MadGypsy]

quick render


This is my pure AS3 version. My Haxe version gives the identical results.

This particular render is done with "blend" lighting. All 4 styles are added together (plus a contrast adjustment that I haven't perfected yet). Considering that I batch group faces by texture my atlases are designed to optimize the crap out of themselves. Some of the atlases for this map are only 16x4. I would like to get it to 4x4. With a static size for lightmaps (due to how I am batching things) it took 42 seconds to load e1m1 from scratch. It now takes <4 seconds. optimizing atlases also wipes around 135mb of instant ram off the slate. It was loading at about 210mb now it's about 70mb. Converting the images to atf and having the parser completely skip all image related stuff in the bsp would shorten the loading time even more and probably cut the ram in about half.

@"blend" lighting - I put a number of ways to get the light in my engine. blend(all at once), flat(brightest), layers(keep atlas separate). Flat is pretty much bullshit. Blend, well, you see. It looks pretty good. Layers is for implementing light styles as was intended.

[Dutch]

The lighting looks fantastic so far. Nice, subtle blending between lit areas and shadows. How does the blend work for lightmaps made from light entities that are right up close to the bsp? Is the blend sharper? I'm just curious what kind of math you have going on behind the scenes.

[MadGypsy]

@math

lol... you think there's math.

light[n] = Math.min( style[i][n] + light[n], 255 );

that's the gist of it but, there is actually a little math extra

//actual line
blend[p] = Math.min( Math.round( blend[p] + (col + (col * (col/12)) ), 255 );

Basically, the higher col is, the greater ratio it will be raised by and then added to whatever color value existed in that position of the blend array. If all that is less than 255, goody. Otherwise, 255.

suppose col is 64 the result would be 96 (32 greater)
but if col was 32 the result would only be 40 (8 greater)

see? So, I'm trying to crank up the lights and keep the shadows BUT without blowing out the shadows and losing all my gradient. That above formula gives decent results. I've tested the results on a number of maps other than e1m1. The results are pretty damn consistent.

fr the record: spike told me to do this. Not the contrast part but, he suggested somewhere in this thread that I add all lightstyles together if I wasn't going to use the animated lights. So, some credit has to go there for anything good about this. Since in regular quake way I would have to get the 4 lightstyles anyway, I decided that adding as I go was better than keeping it layered and using a shader to blend them.

[Spike]

its worth noting that quake's lighting+texture values are linear, but your display is probably not (using a standard gamma of about 2.2). this is both why quake is quite so dark as well as why the banding is quite so horrible at high gamma levels.

srgb framebuffers+textures are supposedly meant to fix all this stuff, allowing the shaders to use a linear colour space.

[MadGypsy]

I stated in my earlier post that I made a number of ways to get light. I would like to be more specific and say - I added a number of ways to get light based on a constant I change in the code. This is not an engine feature. It's just meant to be flexible and allow me to compare various results. Currently BLEND is the default mode, FLAT is doomed and LAYER (ie regular quake lights) is next to implement.

Right now I'm actually bulking up the Content/Export Managers. I'm trying to make this whole file manager package definitive. It doesn't even share any part of a namespace with my engine. It's like an entirely separate project but, my engine utilizes the hell out of it. Not just in an "out" way. When mipmaps and lightmaps are gathered from the bsp they are sent to the content manager. ALL content is managed by the ContentManager except export functions. This is because the ContentManager is meant to be an insta-library. It just seemed weird to me that the library would also act as an exporter so, I put all export stuff in ExportManager. I personally have never heard of a library with a delivery service. Plus, both content and export are different concrete ideas from the same abstract idea so, there is no coupling between serving files and exporting them (ie, the entire file manager doesn't break just because one of it's limbs is wounded)

[MadGypsy]

(col/96)


(col/32)


(col/64)


32 is probably the one, or maybe a 48.....

(col/4


yep, I think this is about as good as this method is going to get

48 from afar

the original post (col/12

[Mindf!3ldzX]

when do i get to download something and try it.
hehe

[MadGypsy]

@when do I get to try it

apparently never OR maybe when you are really really old. I'm trying to release this exactly when my tech is already 20 years old.

I'm just kidding BUT I am just one guy and I'm not copy/pasting a quake engine. I am figuring out a quake engine in a language that Im not really comfortable in and re-solving all the problems differently. Currently my code looks basically nothing like a quake engine. AllocBlock is seriously the only thing straight out of a quake port and honestly I don't like how alloc block is welded to a "whatever the width is so be the height" mentality. My current method has to go behind AllocBlock and go "Hmmm you are only going to fill in the atlas to this maxY + potentially maxFoundHeight...pow2 result, snip". It works well but, there is potential for there to still be removable deadspace.

Really I should probably completely dump AllocBlock and the snip and simply create 1 method that can figure out the most optimized amount of area and arrangement possible to allocate any given set of lightmaps to an atlas. That's probably a very tricky formula and I honestly just don't want to think about it right now.

for the record tough, my current method does an OK job.


Due to power of 2 sizes, that's about as good as it gets. And there is no way for me to know how much of that is all black lightmaps. So, my current method is pretty optimized. Maybe even more than it appears.

However there is also this


which is either a lot of black lightmaps or a bit too much deadspace IMO. These atlases are the same dimensions by coincidence. That is not a static size or anything.

woah, look at this guy. This is how I want them all to be...full