[Kawa]

Back when JonoF's board was still a thing and my screen name was longer, I tried to make a Build game. I still have it and its code, actually. More recently I've been working on a conworld, which relates to two other projects of mine; a popular Starbound mod and a Sierra SCI adventure game. MusicallyInspired was referring to the latter.

Now, MusicallyInspired said this specific forum'd be "close enough", even though literally the only thing EDuke about this new project is that one line in engine.c where cachesize goes negative.

And so, I introduce you, if you'll have it...


While Unkillable was a straightforward FPS, Virtual Firrhna is mostly exploration-based, with various locations mentioned or shown in the other two. For example, here's a (very) work-in-progress remake of a screen from the adventure game that really needs better textures:


Problems that I'd really like some help with:

• I feel my character sprites could be better, but I've no idea how to do this without basically redrawing the whole thing. I don't mean the discoloration on the tail tip, that's trivial. Any suggestions would be welcome.
  
• I am not very good at math, so when I tried to increase the amount of character sprite rotations from eight rotations (45°) to 16 (22.5°), I ended up replacing the single line of math and a conditional to x-flip when needed into a 16-line if-elseif block. Which works, but woah.
  
• There are probably others but I haven't encountered them yet.
  
• Any suggestions on scripting possibilities?

As a token of goodwill, I have a utility of my own design to turn a folder full of PNG files into a series of ART files. Because EditArt is cumbersome and failed to import my stuff, BastART outright crashes when I try, DukeRes won't even consider using the right palette... yeah. CompileArt. A simple command-line tool. With a script file to define offsets (untested) and animation (tested and woah boy that was a hassle and a half). If anybody's interested, I'll clean it up and put it up here for the rest of us. Might add palette.dat generation support, I don't know.

[Jimmy]

I personally still recommend EDITART as there isn't really a tool that does it better, although it's outdated. Here's the latest version of EDITART which is the most stable. Here's a download with a DOSBox wrapper. Here's a guide to EDITART because it does not hold your hand and explains nothing.

My advice for your sprites is that they don't look so good because they look exactly like what they are: 3D Model rips. What you need to do is make better textures for your models, with them being sprites in mind. Also don't forget about consistent shading. Right now your sprites look pillow shaded, which is bad. Your light source should always be in the top left, like classical paintings, and shading should follow accordingly.

[Kawa]

Light source in the top left, simplify textures. Got it.

Edit: You're right, this editart works much better. I've already gotten used to compileart, but this may help test the offset feature so thanks.

[Jimmy]

You're welcome, dude. But I didn't mean to simplify the textures. Take Duke3D for example; The textures are very complex for the time. This helped them in the sprite making process in that all they had to do was clean up the art, but not have to draw details.

[Hendricks266]

Is this a source code mod of KenBuild? If so, are you basing it on the DOS source or JFBuild?

[Kawa]

You have a point, but I figured simplifying the texture on the pants for example would help reduce the noise on 'em. Most of the intended fiddly detail is actually in the face.

This is a JFKenBuild edit, yes.

[Kawa]

Okay, so here's some experimentation.



From left to right: no scene lights and minimal cleanup (as in OP); added top-left scene light and weak bottom right; removed texture from pants; mildly heavier cleanup.

[Jblade]

That looks better - I would say the other issue is that the detail on the head isn't translating well to the low resolution; I'd suggest manually drawing the eyes on once the rest of the sprite is done. It might look a bit too anime but it'll definitely look better with more prominent eyes.

[Kawa]

Thanks. And which of the middle two did you mean looks better?

[Jblade]

Ah I meant the 3rd one.

[Kawa]

Okay, how's this?

⇒

[Jblade]

Much better, the face is much more recognisable that way (the one on the right I mean)

[Jimmy]

Thats a massive improvement.

[Kawa]

I just wrote my own CON variant. If I didn't use the DEF parser, it'd be from scratch.

Okay, so it only supports defining actors, detecting when you bump into one, and deleting sprites, but it's a start.

defineactor 29 //TRASHCAN
{
	onbump
	{
		//no sound or debris yet, lol
		killit
	}
}

In contrast with CON, pun not untended, actor events right now are push, not pull. By which I mean, as far as I understand how CON works, an actor's script runs in full once every tick and checks for certain things to be true, skipping them otherwise. So the above would be something like this in CON:

useractor notenemy 29
	ifpdistl 844
	{
		killit
	}
enda

In VirtuFirr right now, the game code calls for a bump event to be looked up and executed if found, instead, like I understand EDuke32's new events like EVENT_GETLOADTILE to work. I may add if support and switch it around to match.

This doesn't even have a cool name yet.

[Hendricks266]

Writing an imperative style language using the def parser sounds potentially painful.

I wish I could say there is progress on Lua bindings for the EDuke32 version of KenBuild, but there is none. I don't think the KenBuild in our tree even builds at the moment, because the makefile does not build it by default and no one has been making sure they don't break it.

[Kawa]

Hendricks266, on 13 November 2016 - 03:34 PM, said:

Writing an imperative style language using the def parser sounds potentially painful.

It wasn't that bad. I confirmed how CON seemed to work in the afternoon, percolated how to do similar in the def parser while walking mom's dogs, and wrote the stuff so far this evening. And I'm already considering how to do conditionals. Both "if X Y" and "if X { A B C }" style if I can help it.

I have two tables of commands; top-level like defineactor, and block-level like onbump and killit. The tables have token names, command numbers, parse functinos, and exec functinos. There are generic parse funcs for when a command expects no args, a single number, and such, and there's specific ones like possibly the future "ifX Y", which would handle either command or brace block. Either way, they can emit bytecode. The exec funcs can then reasonably expect their args to be in order for use. For example, killit's parse func is SimpleNoArgs, and its exec is KillIt, which is passed the current sprite's number and struct, and its own command ID because lolcodereuse. Braces are/would become a pair of marker values -- -10 and -11 respectively, so to skip one you just track and seek the -11. Single-command ifs would thus probably emit implicit braces. Or rather, I'd probably have ParseScriptBlock handle the difference.

Sleepy rant over.

[Kawa]

It is done.

defineactor 29 //TRASHCAN
{
	ifpdistl 844
		killit
}

This runs, with implicit braces in the conditional.

[Kawa]

Yay, triplepost!

Got some custom textures in:


edit: whoops wrong image

[Kawa]

defineactor TRASHCAN
{
	ifpdistl 1024
		spritepal 3
	else
		spritepal 2
}

[Kawa]

Features added so far:

• Definitions for maps and sounds and such through the imitation CON parser -- less code duplication that way and more familiar.
  
• Sound effects -- looping, randomly-pitched, and in 3D.
  
• A whole lot of renamed engine variables and functions, very much a work in progress. Because who doesn't like lowercase-only unseparated words in identifiers? (spoilers: it's me.)
  
• A non-oneliner thing lifted from EDuke32: PNG screenshots.

[Kawa]

This thread inspired me yesterday to add "random" as a valid filename to pass to the music loader. And then hook that function up to the OSD. So that's now a thing too.