WorldSpawn official WIP thread

[MadGypsy]

@It just seemed that you were almost done with it and that the release would've been rather soonish,

There was never going to be a release. All this stuff is features of a much bigger thing. But, if you need a feature for something I'll hook you up. You participate in my thread and support my work. In my world, that means you get things. I have no problem with that, more than happy to help you out.

@content manager

FYI - my content manager isn't something you can use per se. It is the back-end to everything I make. It has the ability to open, parse, encrypt, compress, save, serve and convert 23 file types (whatever applies). It manages content.

What you want doesn't have a name and since I'm basically just ripping a feature out of a much bigger thing - I don't care what it's called. So.... Wadaroni and Cheese. That's gonna be it's name ~ Wadaroni and Cheese. If you just call it wadaroni I'm gonna act like I don't even know what you are talking about "Wadaroni? What's that? Oh you mean Wadaroni and Cheese?"...lol. I'm only dead serious.



List yo' stuff - If you give me a very detailed idea of everything you want this to do, I'll make as much of that possible as I can without having to write any new features, unless you mention a feature that I decide I want. In other words if you say "and I should be able to draw on the image..." - you ain't gettin that (cause I havent invented any kind of canvas yet) but you might still get everything else you say...depends what you want.

@Umm, I explained what I was looking for and why about a week ago in post #268 and told you I was waiting for your content manager release 3 posts later

Completely missed that some kind of way. (the 3 posts later one) Sorry bout that.

[Mugwump]

Well, I've already explained what I need: a submip generator that doesn't blend the colors of the original textures, so I can have B&W submips with no greys in them.
TBH, I'm not even sure if it'll look better in-game than with blended submips, but I'm really not satisfied with the current look.

Being able to directly edit the submips would be useful (MipDip is supposed to have this feature but that program doesn't seem as user-friendly as TexMex and there's no worthy documentation), but I suppose it falls in the "you ain't gettin that" department...

Everything else I can do with Wally, TexMex and/or regular image manipulation programs. Of course, if you feel like implementing other features that'll reduce the need for third-party programs, all the better, but that's not really a necessity as far as I'm concerned.

@There was never going to be a release.
Your "I'm building a side utility composed of a bunch of tools that I want to rip out of my engine (...) Right now I'm building "photoshop" for wads" comment in post #266 seemed to suggest otherwise. I guess I've read too much into it.

@Wadaroni & Cheese
Cool, I like silly names!

[MadGypsy]

@a submip generator that doesn't blend the colors of the original textures, so I can have B&W submips with no greys in them.

This sentence makes no sense, my friend.

If you want to make "noir" textures that properly maintain the weight of the original image without changing anything but the color of each pixel to the "identical" shade in the grayscale... I can help you.

What do you want to be able to do to submips? edit them in what way?

[Mugwump]

@makes no sense
Yes, I know neither black nor white are "colors" per se. It's just a semantic shortcut that I use for convenience.

@without changing anything but the color of each pixel to the "identical" shade in the grayscale
That's not what I meant. I don't use greyscale at all in these textures, only pure black and pure white. But the submips generated by Wally and TexMex blend black and white pixels into greys. I need greyless submips and I can only see two ways of achieving that: 1) the possibility of generating non-blended submips and/or 2) the possibility of replacing automatically generated submips with manually edited images, like MipDip is supposed to be able to do.

@edit them in what way?
Precisely in the "should be able to draw on the image" way that you warned me I wouldn't be getting... But if you implement point #2 from the previous paragraph, I could find a workaround by editing either full-size textures or submips in PhotoShop or Paint Shop Pro before injecting them in the wad.

[MadGypsy]

Give me some image examples of what you want and what wally is doing to them.

[Mugwump]

Will do but that's gonna have to wait a little - either tonight (GMT+1) or tomorrow, Sunday tops. I need to hijack someone else's computer for that, as my only connected device ATM is my phone... This leaves you some time to play DK2 with MissCandy She was complaining on her thread that she hasn't gotten to play any yet...

[MadGypsy]

I can wait but I have a solution for you

Simply go to imgur.com on your phone. When you click upload it will bring up a menu of where to get the pic from but, it will also list camera as an option. Switch to camera, take a pic of your computer screen, finish upload and post the image.

or just do what you said.

@dk2

I'm busy with the rewrite. I have practically completed the content manager. I only have parsers left to do. That's gonna take a minute and for bsp parser I'm not writing that again. I already know the way I have it written is not going to change at all. I've rewritten that class more times than I can even remember.

[MadGypsy]

I am killing this rewrite. I seriously never went to sleep and have been working on this since 10 hours ago when I last posted here. I'm not going to stop or go to sleep until I have finished this entire rewrite or straight up collapse. Actually, as of right now I don't feel tired or wired. There are some perks to being conditioned to never sleep. I've only been up like 29 hours. In my world that isn't shit. I could probably do 29 more, but I will definitely start feeling this in about another 5 or 6 hours. My one little trick was, I knew I was going to do this so I have completely stayed away from coffee and sugar. No fake high = no crash. I could run a marathon ~ actually, I sort of already am...right?

This rewrite was smart. I have changed numerous things. I can give you one example. In flash you can do this

someFunc (cb:Function)

You can do that in Haxe too but, nowhere in my script is it doing it that way anymore. Now all those conditions are handled like this

someFunc(cb:Event->Void)

which is more proper and forces cb (callback) to be strong typed in and out.

Another major change was my import library. It used to be nothing but one big open Object (Dynamic...same thing). Now it's a StringMap with typedef values. Here is an example

typedef MipEntry = 
{
	var wadname:String;
	var width:Int;
	var height:Int;
	var mip_stream:ByteArray;
	var offsets:Array<Int>;
	@:optional var lof:Int;
};

private static var mip:Map<String, MipEntry > = new <String, MipEntry >();

I'm buttoning this shit down to where there will not be a single generic dynamic value. I should probaby remove that lof from the typedef and think of another way to handle that value. lof is not at all a part of an actual miptex entry but, having that value stored on the mip is helpful for processing. However wadname is also not a part of an actual miptex entry either but without it how is my program supposed to know where this entry belongs in an export context? Meh, this is small beans stuff that I can consider later.

[Mugwump]

or just do what you said.

Yeah, I think that's better for image quality. Plus my phone kinda sucks ass when it comes to navigating websites. I tried to upload a pic from my phone to imgur once and it didn't work.

I seriously never went to sleep and have been working on this since 10 hours ago when I last posted here. I'm not going to stop or go to sleep until I have finished this entire rewrite or straight up collapse.

I understand the benefits of not pausing when working on something but be wary of too much sleep deprivation, it can lead to oversights and downright screw-ups.

[MadGypsy]

tga files are now supported in my project... so is ogg. My content manager got yet another facelift in my rewrite. All my projects are now treated like individual APIs. I still need to rewrite worldspawn to work this way. I have completely lost wad support temporarily. It does everything right except draw mips... can't figure out where my mistake is. That tells me it's not my code... it's some funny-business with haxe or openfl. I'll figure it out... always do.

[Mugwump]

I'll figure it out... always do.

I'm sure you will.

So, I've made a screenie. See how Wally is greyscaling the submips?

[MadGypsy]

My stuff doesn't do that... doesn't even know how.

Now for the good and bad news.

"bad" news: When I said I was going to make your thing I was ready to start right there, that day. This got stretched out and I went to my rewrite. Now I am rewriting and that's what I'm doing.

good news: I'm moving right along on my rewrite and it isn't going to take anywhere near 10 months. Maybe 10 days. I know I said I would bang it out in a saturday but I was obviously grandstanding a bit cause there is no such thing as "banging out 30k lines" in a saturday, especially when I am primarily not even using the original source as reference. However "10 days" is very realistic, especially since it's only been like 3 or 4 days and I am above the daily average that is necessary to pull that off...maybe even damn near half way.

You are going to end up with a Haxe version of what you wanted (Yipee...no captive runtime). I'm going to treat it like it's my first app built off all these libraries I've created. I'm still gonna call it Wadaroni and Cheese... mostly cause I'm not committed to making this a full featured completed thing. It's gonna make you proper mips and little else. I am 100% confident you wont have any gray from my results. I don't see how you could. My thing literally reads every single pixel and finds the closest color it can in the palette. If you are using black and white...you are gonna get black and white.

maybe maybe maybe, using scale to mip could create gray MAYBE. Simply don't do that (if that even happens). I have a skip pixel mipper and it's impossible for it to introduce new colors.

There is a problem with pixel skipping though. Consider (where K = kept and S = skipped pixels)

KSKSKSKS

You see the problem? The right gets clipped, so does the bottom. This can create problems in textures that are bordered like a tile.

now we go to the next mip from the K's above

KSKS

yup the right gets clipped again...bottom too

I think I need to do the below or something far more mathematically complicated that basically results in the below.

KSKSSKSK

Scale mipping does not have this problem but, I haven't tested if there is any averaging of pixels. I actually don't think there is but, I can't say anything definite at this time.

[Mugwump]

"bad" news: When I said I was going to make your thing I was ready to start right there, that day. This got stretched out and I went to my rewrite. Now I am rewriting and that's what I'm doing.

Like I said before, there's no rush. If you feel like prioritizing your rewrite, I understand and that's perfectly fine by me. At any rate, it doesn't prevent me from working on my map.

@grandstanding Yeah, I had smelled a whiff of that...

@I'm still gonna call it Wadaroni and Cheese... And I still like it!

@It's gonna make you proper mips and little else. I am 100% confident you wont have any gray from my results. That's all I asked for.

@maybe maybe maybe, using scale to mip could create gray MAYBE. Simply don't do that (if that even happens). If that's indeed how scaling actually behaves, maybe a workaround would be to add an option to convert to black all pixels from the half of the spectrum that's closest to 0, 0, 0 and convert to white all pixels from the half of the spectrum that's closest to 255, 255, 255? That way it would even work with colored textures and not just B&W/greyscaled, for example to convert colored textures on-the-fly.

@KSKSKSKS You see the problem? Yeah I know, you've already talked about this.

[MadGypsy]

Well, I figured out a problem regarding mips in my rewrite. I haven't fixed the problem yet but, I know this is the problem.

Since I am using openfl (cause I kind of have to unless I want to rewrite as in completely start over for real) I was trying to keep some of the "cross over" language. Mostly keeping ByteArray so, if I ever want to port back to flash it will be super easy. I cannot do this. Neko has major league problems with ByteArray and windows port only seems to agree with ByteArray when it is used for a flash specific class. For instance I can create bitmap data like this

bmd.setPixels(bmd.rect, ByteArrayOfColors)

and in windows port that works fine but using ByteArray to do more complicated things like parsing a bsp or a wad or any file really is a disaster. This is because of a few reasons I have tracked down. One of them is competing over Endian and a sloppy conversion deep in the API that isn't properly honoring or unifying the Endian among Bytes vs ByteArray. It's like my code only knows how to juggle balls but using ByteArray converts one of the balls into a cube and the whole show falls apart. Of course I could simply fix the API (generally a terrible idea unless you know every single spot the change is going to affect...and I don't). I could also be far more specific when creating ByteArrays... almost like creating the conflict early so it will unconflict later. That is just hacky nonsense though. The solution I intend to go with is to ditch ByteArray for everything beyond the most last minute thing (like making bmd from byte arrays) and solely work with Bytes/BytesBuffer/BytesInput but, even beyond that, I am never going to instantiate a fresh ByteArray. All ByteArrays will be derived from BytesInput.getData(); This way, all ByteArrays will be little more than a retyping of the exact BytesInput data. This should fix all my problems. If Neko still complains after all that I have another trick up my sleeve but I am not looking forward to it. Basically I will have to loop through every pixel of data and assign it like this

bmd.setPixel32(x, y, BytesInput.readUnsignedInt())

drawing pictures one pixel at a time is going to slow things down and I truly hope I can avoid this "solution". The good part is: I can easily set a compiler condition that only implements this way when compiling to neko.

#if neko
//do the stupid way
#else
//do the acceptable way
#end

[MadGypsy]

Hah, this shit is trying to fight me every step of the way but, now that I have it's ticket it is failing miserably. I just adjusted everything to use Bytes and it agreed about everything but wouldn't display the image. It claimed it existed, knew the size, everything but, no image. Now you would think there must be some kind of an alpha problem but, I knew that wasn't it. When my code finishes making the image it sends it to the library. Due to everything being by reference, every time I was making a new image I was disposing the one I just made HAHAHA. Lib.img.set(name, bmd.clone()) - suck it, haxe!

Everything works on all platforms without a single compiler condition. Now time to fix miptex/wad stuff based on the methods I just used for BSP.