Real Flash Quake

[Spike]

welding verticies breaks both normals and texture coords. the result will come out looking like glitchy crap, especially if you want realtime lights (although it won't affect shadows).

regarding my sig, FTE QuakeWorld + ftewebgl.html.fmf + ftewebgl.js + ftewebgl.js.mem
put those on a web server somewhere and edit the fmf file. you now have a version of fte running in javascript, running whatever quake mod you told it to. its just fte compiled with emscripten, although it does have a number of features disabled due to emscripten's memory/code limitations.
alternatively, here's someone else's quake engine: http://webquake.quaddicted.com/ which is rewritten in actual javascript. still needs support for webgl etc though.

[MadGypsy]

from here

OK so the tally is in. Haxe is fuckin hard! That's not discouraging me but, it is very true.

It's not very true. Haxe is complex but, once you understand how it is complex it isn't hard at all.

The complexity comes in that, even with openfl, it is not as "simple" as porting flash code to haxe. Mainly this has to do with loading external files. I have to write the c++ way, the neko way, keep the flash way for flash and I'd be willing to bet I have to write an android way. There is no one-script-to-rule-them-all for file management.

Also bullshit. I'm positive, cause, I wrote one script to handle file management and nowhere in it did I add a single compiler condition. I even have it properly parsing sounds(ogg, wav, mp3), images(png) and fonts(ttf) from a compressed zip.

There is also a steep learning curve for optimization. Generally you don't start off worrying about optimizations but, I can save a lot of future time by knowing things like haxe.io.Bytes is faster than openfl.utils.ByteArray, and other such things. Of course, there is nothing easy about writing a complete bsp parser but, trying to do it in a language that can be ported to like 10 platforms makes it infinitely harder.

All of that is bullshit. For one, openfl.utils.ByteArray subclasses haxe.io.Bytes. For two, the BSP parser code is practically identical.

I'm pretty sure when I'm denoobed on haxe I will probably be able to program in any language.

Nope. I am quite "denoobed" and I cannot program in "any" language. Even though I probably can.

Mainly because you aren't getting jack done in haxe if you don't understand the languages you are going to be porting to. I've read like 5 or 6 c++ tutorials to get something done in haxe. Which is akin to watching a 3dsmax video to learn how to model in blender... it bes like that, sometimes.

Yeah, reading 5 or 6 c++ tutorials (instead of 5 or 6 HaXe ones) is probably why I thought all of this stupid crap. I've gotten quite a bit done in HaXe without knowing 99 to 100% of what's going on in the languages I port to.


I made this reply to myself cause I stumbled on this post by me but, now I program quite well in HaXe. Granted, my experience level with HaXe was very low when I wrote this but, it is all so wrong wrong wrong from beginning to end. That was 5 months ago to the day. I picked HaXe up again 2 months ago. I could teach it. Maybe not on an expert level...gimme 2 more months .

[MadGypsy]

@Baker

(When you see x << 4, that is a bit shift that is the "elite" and "fast" of saying multiply by 16 (2 to 4th power). And by "elite" I mean pointlessly confusing with no performance gain on modern compilers to the best of my knowledge.)

Well, I realized today how important bit shifting is. I am assuming it is not like this in whatever C you program in or you would have seen the need as well.

consider

var w:Int = width/2;
//error Float provided where Int expected

var w:Int = cast (width/2, Int);
SomeInternalAPIFunc( w, h, ...otherShit);
//error SomeInternalAPIFunc hates your funcing guts and wont explain why

var w:Int = (width >> 1);
SomeInternalAPIFunc( w, h, ...otherShit);
//success. compile has completed with 0 errors and 0 warnings

However, this only seems to be an issue when compiling to the Neko platform as $smake seems to hate casted ints for it's length property. Regardless, it is at least 1 reason why bitshifting singular vars (ie not ARGB shifting) is necessary... to get Int results instead of Float ones.

[Baker]

whatever C you program in

C has ISO standards of behavior (it's a really long spec) that cannot vary from compiler to compiler. A compiler may offer extensions or non-conformant behavior but there are rules about that too and how it must be handled.

Even really old code -- like 1980s --- works.

Later versions of the spec may introduce something new, but never changes pre-existing behaviors.

Write once; run forever.

[MadGypsy]

@write once, run forever

I believe HaXe (especially with LIME) is working it's way towards that. It still has a good way to go though. Speaking of C, I recently found a pure "to C" compiler for HaXe. I only bother with the C++ way but, I guess if I really needed all the power available the C compiler would be handy.

If you didn't know, when I compile a HaXe script it spits out the code in the language I chose and then compiles that. So, on the most technical level, my game engine is actually a c++ project at it's core (and is compiled for me via MSVS). All HaXe really does is provide me with one language that unifies all other supported languages and a hands-off compilation of that language (unless I want to "hands-on"... I don't). That's really it's greatest appeal to me. I've already learned a retarded amount of languages, I'm flipping the script and focusing on one language that "knows" more languages than I do. If HaXe ever reaches the "write once, run forever" level... even more reason to stick with it and get really good at programming in it.

I'm not gonna lie though, I totally hate Neko. It is by far the absolute hardest platform to track down errors in. I've learned a few tricks but Neko can seriously kiss my ass. Unfortunately, I still make sure that my code works on Neko. I can't bring myself to officially throw Neko in the garbage. When it works it works very well. When it doesn't work, good-friggin-luck finding out why. The best chance you have is to compile often so you at least can have some idea of what isn't broken. I have never been exposed (til neko) to a platform that has one stupid unrelated error for every possible thing that can go wrong. Apparently this:

AL lib: (EE) alc_cleanup: 1 device not closed

is considered an acceptable message for every possible thing that can go wrong cause, it's the only one you ever get when something does. I mean NO stacktrace, not even a friggin line number for where it broke. Apparently everything is an Audio Lib problem? Pbbbt, ridiculous.

[Baker]

Well, you like what you are working with. And that's what is important.

If you are looking to make a web game, what you are working with seems tailored to that.

[MadGypsy]

@like what I'm working with.

I do. It's like (almost) AS3 syntax but, with practically unending port possibilities. You can even export haxe as php. Actually, there is very few languages you can't export to and I don't know what they are. You can even port to Tizen which, I learned recently is the OS for most smart watches.

[MadGypsy]

OK, I take it back...100% and COMPLETELY !FUCK! Neko in every conceivable way. This stupid platform has had me wasting so much damn time trying to fix the most ridiculous shit imaginable. Now there is some bullshit where it refuses to read strings like EVERY other mother fucking platform flash, c++ and html5 all agree..."here's the thing you requested" Neko however "hurr durr, I was supposed to do something? Oh, my bad, I was over here fucking up all your name references so you will never figure out how to fix me."

I AM DONE! FUUUUUUUUCK NEKO YOU TIME MURDERING PIECE OF SHIT!

I was interested in using Neko because it is another one of those VM deals that runs on any system. I felt the cross compatibility was worth the trouble. NOTHING is worth this much trouble. I mean when even flash is smoking you, you completely fucking suck! And honestly, there is a flash standalone player for every imaginable desktop platform. It doesn't even require installation. So, I don't really lose anything by dumping junky-ass Neko. I just need to redirect people to the standalone flash player page for the flash port.

Look at this junk


1) the line to produce this is trace(name)...just the fucking name
2) if you do something like if(_textures.exists("tech04_5")) it swears it doesn't even though it's right there in the fucking list
3) *teleport // && sky4 1_top ????wtf!!?

I have split(" ").shift()ed the crap out of this stuff it makes no damn difference.

In contrast... c++ port (I get identical results on html5 and flash)


well, well, look at that, just names, and they are correct, and I don't get any errors when requesting them.

Just fuck neko. There are probably 100 compiler conditions in my code for neko and 0 for ANY other platform. DONE!

EDIT: If anyone noticed that this is happening all the way down at the BSP parse level and they are wondering why I am so far back... It's because I have a much larger scope of a quake engine in general and I rewrote my parser to be super efficient. This shit used to work on Neko. As my code got better Neko started hating it more and more BUT all other platforms are working faster. A lot faster. However, I am not using the "quake" way for a whole lot of things so, I am by no means saying that making my way like the quake one sped anything up. Actually the opposite is true my "gl_model.(c|h)/bspfile.h" is substantially different.

[Dutch]

Lol!

A while back when you were explaining to me the procedure for identifying where in the code Neko was taking a shit, I was already thinking "Fuck Neko". After reading this, I'm certain of it haha

[MadGypsy]

I actually still figured it out. It's ugly and nasty but EVERY platform except flash includes the null characters from Bytes.readString(16); I never noticed it before because the returned string was used internally...ie anything that got assigned that name, got it assigned with the null characters, so, when I come back and put in the actual name by hand it tells me it doesn't exist BUT, since the internal use of the name had the nulls it would work. The fix is ugly and simple.

#if flash
	name = lumps[MIPTEX].readString(16);
#else
	name = "";
	sname = lumps[MIPTEX].readString(16);
			
	for (L in 0...sname.length)
	{
		if (sname.charCodeAt(L) == 0)
			break;
				
		name += sname.charAt(L);
	}
#end

now the name is only the actual name from the moment I retrieve it from the BSP. Of course now Neko works but, I still don't give a shit about it. What spurred me to fix this was when I was manually testing names and results in c++ and it started crashing, I was like "Oh, hell no!" and made it a point to fix that shit no matter how long it took. It didn't take long. First I traced the string length, which was 16 no matter what. Then I stuck in an 8 letter word, had it regex the word against the stored names til it found the closest one and then traced the charCode at 8 (ie 9th letter). It returned 0 which is Ascii for NUL. From there it was nothing but writing the above loop to grab all the characters up to the first NUL. It ain't pretty but, it fixes names on every platform.

ideally I wish I could do this
name = lumps[MIPTEX].readString(16).split(NUL).shift()
but there is no way that I can think of to put an actual nul character in split(). Nor am I positive that it would actually work even if I did think of a way but, if I could make that work I could get rid of the entire compiler condition and all the other razzle dazzle. On flash target it would just stick in a string with no NULs and return the same string. Hmmm, I wonder if a completely empty string counts as NUL.

If I would have used the "things you cannot see" method from the beginning, my whole Neko post yesterday wouldn't exist.

@Dutch - what I told you regarding how to troubleshoot neko

I figured out a trick that makes it better. Simply make a .bat with a PAUSE command at the end. Compile for NEKO, if it crashes run it via the bat. Neko always loads with a command shell and if it crashes it closes itself and the shell BUT if you run it from a bat with a PAUSE, it doesn't crash the shell and you can read everything that went wrong. It's not as robust as flash on the error reporting but, it's better than only getting that "one device not closed" error.

EDIT:

final

name = lumps[MIPTEX].readString(16).split(String.fromCharCode(0)).shift();

works on all targets. I forgot about fromCharCode. Works great. For anybody less codey that doesn't understand that, it's very simple. The string gets split into an array on every nul. The nuls happen after the name so I get (shift) the first position from the array which is all the letters up to the first nul.

name = "textureNULNULNULNULNULNULNULNULNUL"
//split - the NULs become the commas and since there is nothing between them the new index is just an empty string
name = ["texture","","","","","","","","",""]
//shift - ie get Array[0]
name = "texture"

I guess I could also do this...same thing

name = lumps[MIPTEX].readString(16).split(String.fromCharCode(0))[0];

Honestly, I don't really mind when things go wrong or I find these really deep issues that are only issues when I try to manually do stuff. I just got better at HaXe programming... stuck another fact under my belt regarding it's behavior from platform to platform. I will never forget these things and this is one less mistake that I will ever make. I have only been programming in HaXe for a handful of months and I could write a book about things to consider from platform to platform. I can't even begin to count how many times I have written perfectly working code and then spent hours messing it all up in an attempt to try a less obvious way that utilizes types and concepts that are buried in the API. Some may consider it a waste of time but, you don't get Spike level of good at things by just making things work or relying on age-old obvious things to accomplish all your goals. An example of this is images. All my old code relies on looping through values and assigning colors pixel by pixel til all the pixels are assigned. This is because "supposedly" this is how you do it. Guess what, there is a faster way. Run those same loops on a ByteArray or platform equivalent and dump the entire buffer to the image. It's a lot faster to .setInt32 than it is to .setPixel32. Essentially every setPixel32 is a draw call and that shit is expensive. setPixels(buff) is also a draw call, ONE draw call... as opposed to height*width of them. When you consider that you are actually reducing the draw calls to NumTextures instead of AvgHeight*AvgWidth*NumTextures the difference in time is staggering.

I'm about to take it even further. Currently, I call new BitmapData() on a temporary BitmapData instance for every iteration of the loop. new is expensive and god only knows how much garbage collection hates me for this. The new method will be to set one temp bitmapdata instance to memory and simply keep overwriting it. The tricky part MAY be handling differences in dimensions between images. The height and width properties are read-only and set through the constructor (new()) so getting around that might be impossible BUT, if it's possible I guarantee you I will figure it out. Possibly a matrix can be used some kind of way. The reason for this is because BitmapData is nothing but my "reader" BitmapTexture is the final destination. Instead of creating NumTextures of BitmapData and then dumping each to BitmapTexture, I hope to only create one BitmapData and dump it's current state to BitmapTexture. This is gonna be super tricky. Then again, maybe I could just create a fromBytes method for BitmapTexture and get rid of BitmapData altogether. This could create a lot of RGBA, BGRA, BGRA_EXT problems though as each platform is handled a bit differently. That's why I use BitmapData, it already considers the platform for me. Also BitmapData allows me to draw against a matrix for power of 2 conformity. I would have to add that as well to BitmapTexture...at that point I might as well stick with BitmapData cause I'd just be rewriting half of it into BitmapTexture.

[Baker]

When working with something that translates code to another language ...

... You'll find out:
1) The quirks and inconsistencies of the tool
2) The subtle mechanics of any given language will explode on you from time to time.

I know you like to say "you know all these languages".

But you won't hear an experienced programmer say something like that because:

There are no languages, only syntax/rulesets and a command set (think abstraction layer). It's all just pushing bytes around. It becomes machine code in the end, that's the only language.

(So, for instance, you may read comments occasionally from Spike where he talks about what is "really happening" or old discussions where MH and Spike argue about what's more optimal.)

All higher level languages are translators (abstractor layers) to a machine code.

You are experiencing a problem where the code is being translated twice. Once from a higher level language ---> to various other languages ---> machine code.

You'll run into inconsistencies again and again and again.

You might consider picking one target and then only have to deal with one set of inconsistencies. You'll never find the end of problems if you are targeting 3 or 4 different translations.

[MadGypsy]

@I say I know all these languages

It's just the simple way of saying what you just said. I am a syntax remembering monster plus more than just familiar with built-ins and common API's for said language. I've actually been waiting 5 years for you to address my claim cause what you said is exactly why I can successfully program in so many languages. I fully understand this is just the same shit over and over with little more than syntax switcheroos. That's the entire power to banging out language after language.

for(i=0; i<something; ++i)

haxe
for(i in 0...something)

do you think I had to relearn what a loop is to understand that? Of course not.

@pick one platform or be prepared for problem after problem

I choose problem after problem. I personally consider choosing one platform to be a wimpy decision. My environment supports numerous platforms. My project will work on them all (probably even Neko). Sure, the battle becomes greater but so does the reward. Honestly, if it wasn't for problems I would probably be bored to death. Every time I encounter some big problem buried beyond stacktrace land and fix it (which, so far, IS every time) I not only get better but my already ridiculous confidence levels become higher.

If you think about it, your message to me is to avoid the learning curve at all costs. If I had that mentality I'd still be stuck with nothing but HTML under my belt (my very first language and I learned it in it's entirety in 2 hours via a 20+ page pdf). It was that drive to know more, learn more, try harder that brought me to the point today where I can pick up any of around 20 languages without blinking and start coding well well well beyond "Hello World" AND generally without docs. SOmetimes I need docs for PHP and Javascript for more advanced stuff but, I pretty much do it all by the seat of my pants and edge of my memory. I don't know what kind of C that fitzquake source you gave me is in but, I could program in it. I say this because I've been reading the shit like a book for weeks now and very very few things confuse me within that source. My only point is that my penchant for driving around the learning curve in a formula one racer is why I am definitely a completely bad-ass programmer. I can even mentally decipher complicated languages used in a complicated context regardless of whether or not I even know that language. It's because I have shoved so many different syntaxes and language structures under my belt that I can do this. I'm like a rosetta stone for code and I'm getting better EVERY SINGLE FREE MINUTE.

I believe you aspire to be a bad-ass C(flavor) programmer and you probably already are. I aspire to be a bad-ass programmer period where no language is a mystery to me. Where there isn't a line of code on this planet that I cannot read and understand immediately. Where I could practically guess my way through programming in a language I know NOTHING about. I will tell you, I'm a lot closer to that than you may believe. Less than 6 years here and I am already building an engine by the seat of my pants. I don't know if you noticed but, I'm not asking a lot of questions these days.

PS> I dropped out of 8th grade 4 times and never went back. I'm doing all this on a 7th grade education.....LMAO! I know that's an extremely loaded statement but, it's true on paper. The off paper truth is I figured all this shit out with nothing but Google (and you/spike for the itty bitty parts where that applies, out of the whole of 20 languages).

@you won't hear an experienced programmer say something like that

woops missed that. Uh, what the fuck do you think I am? If I'm not experienced, nobody is. 16 years and 20 summin languages dude. That's more than 33% of my life doing this. I bet you think something like I learned 20 ways to write a function and I'm trying to call that "knowing a language". Yeah, it took me 16 years to do that. Wake up, bro...16 years is a hell of a lot of learning time. And it's actually 20 years but the first 4 I wasn't very dilligent or active.

[Baker]

If you think about it, your message to me is to avoid the learning curve at all costs.

Not at all.

But I said in a previous post, you don't appear to be picking what you are learning, it is picking you.

You'll bounce around in an infinite loop, there's always more to learn.

But only you know your goals. But I know when I'm doing something, I like to complete it.

Pure science: Knowledge for the sake of knowledge
Applied science: Knowledge only for the sake of achieving a goal

I live in #2. But that isn't the right answer for everyone and maybe endless exploration is what you are really after.

[Baker]

I don't know what kind of C that fitzquake source you gave me is in but, I could program in it.

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.

[Spike]

my problem is that I never really embraced the higher-level languages.
any use of functions that allocate temporary objects or whatever make me feel dirty. string concatenation more than once feels like a sin.
really though I just find weakly-typed languages annoying.
my hypothesised OCD does not allow me to write javascript code...

C is annoying too though. All that manually-written glue code and other nightmares, gah.
C++ is one way around that, but half the code I see written by others just ends up being a maze of templates and classes that its a nightmare to try to debug all the things that the original writer was too lazy/incompetent to fix.

There is no perfect language. Just use the best tool for the job, and hope that the job's requirements do not change in the future.

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