Page 1 of 1
WHACK for DSB
Posted: Tue Nov 27, 2007 12:18 am
by 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.
Posted: Tue Nov 27, 2007 5:06 pm
by 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 ?
Posted: Tue Nov 27, 2007 5:21 pm
by 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.

Posted: Tue Nov 27, 2007 5:31 pm
by Remy
it seems Remy's test dungeon has a bit of a bug too
Oops...
That means there's a bug in DDM...

Posted: Tue Nov 27, 2007 9:36 pm
by Sophia
I just noticed that if you're using an ext-style wallset, hazes will render incorrectly.
I will fix this, too.
Posted: Wed Nov 28, 2007 8:03 am
by 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
Posted: Wed Nov 28, 2007 8:58 am
by 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

)

Posted: Fri Mar 28, 2008 5:47 pm
by 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
Posted: Fri Mar 28, 2008 8:08 pm
by 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.
Posted: Fri Mar 28, 2008 11:45 pm
by 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

Posted: Sat Mar 29, 2008 10:24 am
by ian_scho
I played some more. Then searched the forum
Sophia wrote: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!
Posted: Sat Mar 29, 2008 4:12 pm
by 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

Posted: Sat Mar 29, 2008 4:27 pm
by 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.
Posted: Sat Mar 29, 2008 7:03 pm
by Sophia
ian_scho wrote: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.
ian_scho wrote: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)
ian_scho wrote: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.
Posted: Sun Mar 30, 2008 10:35 am
by 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.
Posted: Wed Apr 02, 2008 11:32 am
by 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.
Posted: Wed Apr 02, 2008 11:55 am
by 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.
Posted: Wed Apr 02, 2008 4:31 pm
by 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.

Posted: Wed Apr 02, 2008 7:52 pm
by Sophia
Parallax wrote:Sophia wouldn't be distributing the source along with the execuable if she didn't want people to modify it, right?
Go nuts.
Parallax wrote: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:
Parallax wrote: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.
Posted: Thu Apr 03, 2008 12:22 am
by Sophia
Updated version now uploaded.
Posted: Thu Apr 03, 2008 4:14 pm
by 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.

)
Posted: Thu Apr 03, 2008 9:34 pm
by Sophia
Parallax wrote: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.

Posted: Fri Apr 04, 2008 2:15 am
by 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.
Posted: Fri Apr 04, 2008 2:32 am
by 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.
Posted: Fri Apr 04, 2008 3:05 am
by Sophia
Parallax wrote: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.
Parallax wrote: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.
Posted: Mon Apr 07, 2008 5:24 am
by 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)
Posted: Mon Apr 07, 2008 3:57 pm
by Parallax
Thank you so much! On to the flooritems and relief maps!

Posted: Sun Jun 15, 2008 12:28 am
by 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...