WHACK for DSB

[Sophia]

Get it here (version 0.74)

Pretty self-explanatory really. It's as ugly as ever, but it works.

Edit the ini to tell it what you want, run the program, and copy the files wherever you want them. There's also a dsb_out.txt that contains Lua code you can cut and paste to use your new wallset.

[linflas]

i *had* to see how to implement a custom wallset in DSB : i took Remy's dungeon view example and added the dsb_out.txt lines in dungeon.lua.
i have an error on the 26th parameter of dsb_make_wallset_ext. the "gfx.window" thing is not a "bitmap" so i added a line for it gfx.window = dsb_get_bitmap("CIRCLE") where circle.bmp is a nice... circle.
i still have the error so i tried to put "nil" also, but it does not work at all.
where am i wrong ?

[Sophia]

There are a few problems that I can see... what error message, exactly, are you getting?

The first problem is with WHACK itself: the default output says "gfx.window," but it should be "gfx.wallwindow." I'll fix that when I get a chance.

The second problem is that it seems Remy's test dungeon has a bit of a bug too: the calls to dsb_level_wallset all set the wallset on level 0, so if you just change the first one to your new set, the others will change it back.

After correcting these two issues though I was able to run WHACK, copy and paste the bitmaps into the dungeon dir, and paste the dsb_out.txt into the Lua code, and it worked fine.

Oh, one other thing, just in case you forgot: don't forget to change to Compile=1 in the ini or you won't ever get a new version of the dungeon produced.

[Remy]

it seems Remy's test dungeon has a bit of a bug too

Oops...
That means there's a bug in DDM...

[Sophia]

I just noticed that if you're using an ext-style wallset, hazes will render incorrectly.
I will fix this, too.

[linflas]

i had already noticed Remy's bug and commented all dsb_level_wallset lines..
here are the lines i pasted at the beginning of his dungeon.lua :

Code: Select all

--Wallset test
gfx.ws_front1 = dsb_get_bitmap("WS_FRONT1")
gfx.ws_front2 = dsb_get_bitmap("WS_FRONT2")
gfx.ws_front3 = dsb_get_bitmap("WS_FRONT3")
gfx.ws_left1 = dsb_get_bitmap("WS_LEFT1")
gfx.ws_left1alt = dsb_get_bitmap("WS_LEFT1ALT")
gfx.ws_left2 = dsb_get_bitmap("WS_LEFT2")
gfx.ws_left2alt = dsb_get_bitmap("WS_LEFT2ALT")
gfx.ws_left3 = dsb_get_bitmap("WS_LEFT3")
gfx.ws_left3alt = dsb_get_bitmap("WS_LEFT3ALT")
gfx.ws_pers1 = dsb_get_bitmap("WS_PERS1")
gfx.ws_pers1alt = dsb_get_bitmap("WS_PERS1ALT")
gfx.ws_pers2 = dsb_get_bitmap("WS_PERS2")
gfx.ws_pers2alt = dsb_get_bitmap("WS_PERS2ALT")
gfx.ws_pers3 = dsb_get_bitmap("WS_PERS3")
gfx.ws_pers3alt = dsb_get_bitmap("WS_PERS3ALT")
gfx.ws_far3 = dsb_get_bitmap("WS_FAR3")
gfx.ws_far3alt = dsb_get_bitmap("WS_FAR3ALT")
gfx.ws_pers0 = dsb_get_bitmap("WS_PERS0")
gfx.ws_pers0alt = dsb_get_bitmap("WS_PERS0ALT")
gfx.ws_floor = dsb_get_bitmap("WS_FLOOR")

wallset.whack_set = dsb_make_wallset_ext(gfx.ws_floor, gfx.roof, gfx.ws_pers0, gfx.ws_pers0alt, gfx.ws_pers1, gfx.ws_pers1alt, gfx.ws_pers2, gfx.ws_pers2alt, gfx.ws_pers3, gfx.ws_pers3alt, gfx.ws_far3, gfx.ws_far3alt, gfx.ws_front1, gfx.ws_front2, gfx.ws_front3, gfx.ws_left1, gfx.ws_left1alt, gfx.ws_left2, gfx.ws_left2alt, gfx.ws_left3, gfx.ws_left3alt, nil, nil, nil, nil, gfx.window)

dsb_level_wallset(0, wallset.whack_set)

here's the error message in the LUA ERROR window :

Code: Select all

C:\Documents and Settings\...\Desktop\dsbtest26a\dungeonview/dungeon.lua: dsb_make_wallset_ext requires Bitmap in param 26

[linflas]

ok, i found the problem by analyzing the log.txt :
- dsb_out.txt lines must be pasted in startup.lua, not in dungeon.lua
- the dsb_level_wallset function must be written *after* dsb_text2map in dungeon.lua or DSB complains about an unknown Level number
(i guess these info are interesting for Remy )

[ian_scho]

Hi, I'm playing again. This time with WHACK. I get the following error message:

Code: Select all

No se encuentra el punto de entrada : No se encuentra el punto de entrada del procedimiento hline en la biblioteca de vínculos dinámicos alleg42.dll. 

Which roughly translated means $*@% you!
I've tried placing the alleg42.dll file in both the WHACK and the /[win]/system32 directory and no joy. I even tried dropping the thing onto regsvr32.exe, just in case. So.... Where is The procedure entry point then?

TIA

[Sophia]

¡Ventanas Estupidas!

I recompiled the .exe to support the newer version of the Allegro DLL that DSB is now using. Just download WHACK again and all should be well.

[ian_scho]

"Operation Complete" woo-hooo. Thanks

I have the bimaps now, albeit with obvious lines on some of the pictures. Will go and play a bit more

[ian_scho]

I played some more. Then searched the forum

Any 256-color PCX image should be fine.

I changed the bmp file to 256 colours, note the 'u', and it made the wallset without any lines. Cool.

I notice now that the utility doesnt generate any alcoves or stairs.

Now to try to import this stuff into a dungeon!

[ian_scho]

OK!

Got this beast working. Notice the difference here?

Code: Select all

gfx.01_front1 = dsb_get_bitmap("01_FRONT1")
gfx.ws_01_front1 = dsb_get_bitmap("01_FRONT1")

The first one gives me an error message "...malformed number near .01_front1". As you can see from the second line, my tiny code-monkey-like brain changed the first part from the underscore and it works...

I assume the graphics.dsb file are these images compiled, and we dont need to distribute the source bitmap files.

One thing I've noticed is a possible bug in the generation of these files, for the floor (the tiled effect of the ceiling is my fault, me thinks). I need to play some more, but here's a snapshot anyway, of what I've got. I wonder if the floor image has been shunted down a bit, if you know what I mean?



Original, floor.bmp

[Gambit37]

Is that bottom image the SOURCE image you're putting in Whack? If so, it's no good as it's already been drawn with perspective. You want a standard, tiled, flat 2D source image and whack applies the perspective itself. This is why it looks squished in your demo.

[Sophia]

The first one gives me an error message "...malformed number near .01_front1".

This is Lua. You're trying to have a string table index start with a number, which confuses it. Your fix (making it not start with a number) is probably the best one.

I assume the graphics.dsb file are these images compiled, and we dont need to distribute the source bitmap files.

Correct. A DSB dungeon for distribution needs only dungeon.dsb, graphics.dsb, and, if you're using them, objects.lua and startup.lua (or objects.lxx and startup.lxx, if you're using compiled Lua to hide your scripts from prying eyes)

One thing I've noticed is a possible bug in the generation of these files, for the floor

What Gambit said.
Your floor is already suitable for DM, so WHACK is just further deforming it. If you had a flat bitmap, it'd apply perspective properly.

[ian_scho]

Thanks all. I actually thought that might be the case while pushing my daughter on a swing earlier.... Why these things pop into my mind I don't know. Will play some more!... With Gambit's graphics, for example.

[ian_scho]

It's great that we have transparency (power pink, 255, 0, 255) for walls, but I notice that it only works on ws_02_front1.bmp - the front first facing wall. The other walls are lose this value as you add your calculations for brightness etc. This means that I now manually replace the calculated colour in an editor, back to the original power pink value. Still with me? I'll hopefully post a screen shot soon.

[ian_scho]

I scratched that idea, and used black instead. That doesnt get graduated to black along the sides and is a pain to replace the colours with. So it was black to power pink for each picture, but comes up great. I ended up replaceing a bit too much foliage, but the tranparency looks great.

[Parallax]

Ideally, you'd want WHACK to not blend power pink with the fading color when creating the projected bitmaps. Or at least I would.

Fortunately, with the source available, all it takes is time and dedication to turn WHACK into a more competent piece of software. Sophia wouldn't be distributing the source along with the execuable if she didn't want people to modify it, right?

If I had the time and inclination, here's what I would do:

- Exclude power pink pixels from being faded.

- Include an option to tile the floor and ceiling bitmaps to the play squares exactly.

- Offer the option to output floor and / or ceiling tiles separately for each square, thus making the creation of flat, horizontal flooritems less painful.

- Increase the allowed resolution of input bitmaps by a factor of 4 of each side, and that of output bitmaps by 2 on each side, so that graphics can be generated for a screen resolution of 1280x960, with the output being somewhat clean.

- Include a blending algorithm to clean up output bitmaps and get rid of jagged edges.

- Add "depth" bitmaps to make the creation of bas-relief possible. This requires rewriting the bitmap generation algorithm to make it draw all output bitmaps from back to front.

Darn, I should have posted this yesterday, and said I had done it already. There was some potential for rickrolling there. Oh well, insight is 20/20.

[Sophia]

Sophia wouldn't be distributing the source along with the execuable if she didn't want people to modify it, right?

Go nuts.

Exclude power pink pixels from being faded.

This is pretty easy. I'll do this and release a 0.73.
The other options are more complex, and I'll think about them, but I'm not promising anything.

Edit:

Include an option to tile the floor and ceiling bitmaps to the play squares exactly.

Offer the option to output floor and / or ceiling tiles separately for each square, thus making the creation of flat, horizontal flooritems less painful.

These two options will probably have to go together. The DM floor was drawn by hand, and no actual 3D perspective (at least, none that I could find) will exactly align with it, so flooritems will probably have to be rendered "by section" like walls are.

That said, the floor generated by earlier versions of WHACK didn't really match the DM floor very well at all. I've tweaked some of the defaults (and added a few more options) and the one in 0.73 is a lot closer.

[Sophia]

Updated version now uploaded.

[Parallax]

Cool. Thank you.
What about the resolution increase? Do you think it would take too much time to implement?
(Yeah, I know I'm pushy. It's your own fault for being so nice. )

[Sophia]

What about the resolution increase? Do you think it would take too much time to implement?

I'm not sure.
What would you use it for, though?

DSB certainly can't run at that resolution.

[Parallax]

It cannot because there is no need for it. There is no need because there are no graphics for that resolution. There are no graphics because no custom bitmap maker generates them at that resolution. And none of them do because there is no need for them to... lather, rinse, repeat.

In other words, I'm hoping to break the cycle. And if nothing else, graphics that are 4x higher resolution than needed are good to get out of WHACK because then they can be put in photoshop or gimp for further treatment with a good probability of the end result being high quality. It's easier to make lores from hires than the opposite.

[Gambit37]

Indeed, I thought that's why you'd want it -- supersampling a nice fat image down to DSB (or RTC) resolution should give excellent results.

[Sophia]

lather, rinse, repeat

It's not really that simple. DSB just plain doesn't support any resolution greater than 640x480, and it's not just lack of graphics-- that's one limitation, sure, but I'd have to rewrite all of the rendering code, clickzone handlers, and so on, and I'm not exactly excited at the prospect.

if nothing else, graphics that are 4x higher resolution than needed are good to get out of WHACK because then they can be put in photoshop or gimp for further treatment with a good probability of the end result being high quality

This makes a good amount of sense, though.
I'll add something like that this weekend. If WHACK is ever going to support any kind of blending (not that it will, but you never know) it'll need higher resolution images anyway, and in the meantime it'll be good to be able to get them to play with yourself.

[Sophia]

New version uploaded.

Now you can set InRMod and OutRMod (Resolution Modifier), to control the multiplier that is applied to the sizes of the expected input bitmaps and the generated output bitmaps. That is, if you set both InRMod and OutRMod to 2, WHACK will expect the input bitmaps to be double normal size and it will generate output bitmaps at double the normal size. Simulated lo-res is not supported at RMod values > 1 (as there's just no point)

[Parallax]

Thank you so much! On to the flooritems and relief maps!

[takis76gr]

I download your whack wall generator , is very good.

Is it possible to create walls for Eye of the beholder size wallsets?

My dimensions in pixels are:

ws_pers0 & ws_pers0alt=48x240
ws_pers1 & ws_pers1alt=48x190
ws_pers2 & ws_pers2alt=32x118

ws_front1=256x192
ws_front2=160x118
ws_front2=96x74

ws_left1 & ws_left1alt=48x192
ws_left2 & ws_left2alt=96x118
ws_left3 & ws_left3alt=96x74

ws_far3 & ws_far3alt=42x72

ws_ceil=352x74
ws_floor=352x116

entire backdrop=352x240


Which configuration could I make or does it need to change
whole source code?

I don't understand your code well , I have used allegro library in the past , but I don't understand your algorhythm.

Thank you...