Porting Voxlap

[Sonarpulse]

OK, got the first section of voxlib.txt, "File related functions", converted it to doxygen, stuck it in voxlap5, and committed it.

[Sonarpulse]

OK, did the next section, "screen functions" too. If somebody could help me with this, as voxlib is a pretty big file and this is pretty tedious, that would be great! Just state which section your doing here so nobody duplicates your efforts.

[TheSifodias]

Little question: If you are porting voxlap, then wouldn't you have to still make the Ace of Spades programming for Voxlap? Anyways, good luck! I am no codemonkey myself, but I'm sure you'll find help somewhere in this internet realm?

[VladVP]

Little question: If you are porting voxlap, then wouldn't you have to still make the Ace of Spades programming for Voxlap? Anyways, good luck! I am no codemonkey myself, but I'm sure you'll find help somewhere in this internet realm?

Uh... what? I don't quite understand your post...

Yes, we're expecting to remake ace of spades from scratch, with the ENet; and these ported voxlap libraries, when we're done. Aren't that also said in the original main post? o.O

What do you mean by that some of us will find help? I assume that most people here are fairly decent programmers.

And is that reference to us people trying to help you gamers gaming as "codemonkeys" meant as an offense?

[TheSifodias]

Oh, whoops, did not know codemonkeys was an offensive word... Not sure where you got the "some of us" part, but I was referring to the post before me, where it said he needed help. Sorry for my tricky english.

[Sonarpulse]

I think the misunderstanding was that my post was more a shout-out to Vlad and Cajun, who have been great help. Though if random people want to join the effort that is great too.

[Cajun Style]

then wouldn't you have to still make the Ace of Spades programming for Voxlap?

Yes, this is mainly the old graphics engine being ported. Although I have a great suspicion the original AoS was based on the example game that comes with Voxlap.
I've seen your comments Sonar. I've replied to them. I'm not sure how to exactly and navigate use github. I reached the places I did via links in my e-mail.

[Sonarpulse]

Ha! what a coincidence, I just pulled your first set of changes related to compilers errors and committed them (with some modifications). Yeah, I understand why the whole double parentheses thing is needed no when using statements in an expression, so that's fine. The biggest change I made is the array in game.cpp needed to be signed so I made the initialization use an explicit cast to avoid the narrowing error.

[Cajun Style]

If you promise you'll keep your commits nice and consistent, I'll start merging instead of rebasing. I haven't looked at conservative yet. In fact I haven't done much this week. I'm rewriting genmipkv6, but I have no idea what it's supposed to do yet. The function caught my attention, because umulmip[0] has a troublesome value. It does access memory you'd expect is invalid almost right away... but maybe the rest of the engine makes sure it is valid.

[Sonarpulse]

Oh, I still think you should rebase and not merge, cause then I can't rebase :D without rebasing your stuff myself, and then you have to rebase of my rebase anyways... and well you get the idea.

I'm really not redoing conservative's history now though (I said so once before most recently ...and then did it anyways), so it should always be doable to rebase off that. If you want to know what the branch names are, I made a post of about it all on page 3 out of 4, though not all of them are implemented. Basically though conservative is for stuff that's an unequivocal improvement. If it makes it better than before whether we are using assembly on x86-32 or pure C on ARM-64, it goes there.

Just looking at the name, genmipkv6 GENerates the MIP maps for KV6 files. I took a look at what you started. I would caution you that longs should 64 bit values yet. MSVC treats char as 8, int as 16, and long as 32 regardless of the architecture, and while this function may cause bugs with a gcc build, the game is pretty robust (with the original asm) on MSVC. Yes eventually we will be changing some a lot of longs to uintptr_t, which of course could be 64-bit, and boy won't debugging that be fun. But I can't think of a single case were we would replace long with a fixed with 64 bit type unless we were changing the algorithm.

However, genmipkv6 did used to have some inline asm, and as we know from kv6draw, not all of the commented out C works. One of the earliest commits on no_asm replaced the asm with C, you may want to look at it for reference.

[Sonarpulse]

Just added doxygen for "sprite related functions" and pushed to github. I'll probably update the README next with the description of the planned 4 branches as it's out of date ...again.

[Cajun Style]

I thought mipmaps had to do with textures???

Oh, I still think you should rebase and not merge, cause then I can't rebase :D without rebasing your stuff myself

Are you saying it's easier to apply my changes to other branches, if I rebase? Then I'll continue doing that. It sort of breaks the history, which is one of the key features of a VCS. It's kind of reassuring to know your VCS can roll-back any change you've made.
Talking of reassuring: no_asm has been compiling and "running" for quite a while for me on Linux and Windows. On the other hand: GCC still chokes on the assembly of conservative (so doesn't compile).

[Sonarpulse]

Here is Ken's documentation:

Code: Select all

	//Generate 1 more mip-level for a .KV6 sprite. This function generates a
	//   lower MIP level only if kv6->lowermip is NULL, and kv6->xsiz,
	//   kv6->ysiz, and kv6->zsiz are all >= 3. When these conditions are
	//   true, it will generate a new .KV6 sprite with half the resolution in
	//   all 3 dimensions. It will set kv6->lowermip so it points to the newly
	//   generated .KV6 object. You can use freekv6() to de-allocate all levels
	//   of the .KV6 object. To generate all mip levels use this pseudo-code:
	//      for(kv6data *tempkv6=mykv6;tempkv6=genmipkv6(tempkv6););
	//kv6: pointer to current MIP-level
	//returns: pointer to newly generated half-size MIP-level
kv6data *genmipkv6 (kv6data *kv6);

Yeah, rebasing breaks the history, which is unfortunate. But at least each revision is still there, just in a different order. My plan is once no_asm is bug free, to temporary revert each revision and thus fix the assembly one bit at a time until I am back to conservative.

[RedBull]

Im still looking forward to the final outcome of this project. Keep it up!

[Sonarpulse]

Thanks for the support! Don't worry we are still working steadily, even if there hasn't been much to announce to keep this near the the top of the first page.