123
-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|432|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Retro Stuff -> My latest Game - Boothill

Posted : Wednesday, 18 September 2019, 10:46
zzoom

My latest Game


Started a remake of boothill, but got this crazy Idea I might make it in B3D

Anyway, this has given me inspiration:

JayenKais STL converter

-=-=-
Happy coding!
Posted : Wednesday, 18 September 2019, 11:05
Jayenkai
Cool!
Is that the two-player western shootout game?

-=-=-
''Load, Next List!''
Posted : Wednesday, 18 September 2019, 18:55
Jayenkai
It just occurred to me.
You can't load the STL back into B3D..
(Not without an extra load routine, anyway)

It's not hard to convert pixels into block data, though, and given the simplicity of the original game, it shouldn't be too hard for B3D to cope with it all.
Suggest you create one cube, then make meshes for each "sprite", and AddMesh "basic cube", sprite until you've created all the different sprites.

I'll do an example code thing tomorrow, if you'd like.

-=-=-
''Load, Next List!''
Posted : Thursday, 19 September 2019, 08:40
zzoom
Yep, its the western thingy - got all sorts of crazy ideas for it - but in the first instance need to try and stick to the original - ish, to get it off the starting blocks.

Here's my planned conversion process:

1. Import pixels using Jayenkai's tool
2. Export to STL
3. import stl to blender
4. export in blender to.b3d

Unfortunately, my computer with the blender + b3d plugin is dead - so got a little work to do. Fun times

-=-=-
Happy coding!
Posted : Thursday, 19 September 2019, 08:52
Jayenkai
That's an awfully messy way around it!
All you need to do is import pixelart and convert to blocks.

I said I'd do you an example, and .. I will, just .. Not right now! Currently having to do backups and things, and would rather it not break!

-=-=-
''Load, Next List!''
Posted : Thursday, 19 September 2019, 09:49
Jayenkai
OK, here you go..




BoxSprites (.zip)

What you'll need to do from that point is move all the BoxSprite objects off to an unseen area, then CopyEntity the BoxSprite you need per frame, move it where you need it, and free it away afterwards.

-=-=-
''Load, Next List!''
Posted : Saturday, 21 September 2019, 20:06
zzoom
Thanks JayenKai, giving this a whirl now - yesterday I confused my noggin by YET again trying to suss the nuances of native collision detection - ended up writing my own proximity function:



-=-=-
Happy coding!
Posted : Saturday, 21 September 2019, 21:10
zzoom
Getting there... slowly. Think more sleep is required to get to the bottom of how to position a BoxSprite like a 3D entity....?

https://socoder.net/s2upload.php# (JKSprites.zip contains my code and a 32 x 32 cactus.png)

Am I missing something by not copying the BoxSprite 'off screeen' before trying to refence it - I think this is purely meant as part of the load_entities function whereby the .pngs can be convereted on the fly to manipulable 3D entities - however my attempts at positioning CactusSprites are resulting in MAVs? Maybe just a syntactical thing on my part.

Thank you for your help so far




-=-=-
Happy coding!
Posted : Sunday, 22 September 2019, 00:16
zzoom
Morning - I've sussed how to move the Cacti - in the function.

However - I'm getting MAV's trying to manipulate the entities outside of the function - getting there!

-=-=-
Happy coding!
Posted : Sunday, 22 September 2019, 00:54
zzoom
Thanks JayenKai - got there in the end

[img][/img]

-=-=-
Happy coding!
Posted : Sunday, 22 September 2019, 04:37
Jayenkai
You could probably do with changing the z axis on the scaleentity pixel, so that the objects look a bit chunkier, I reckon.

Also, don't go overboard with "sprites"
My lazy technique is VERY polygon heavy. Each "pixel" ends up being 12 poly's, and it doesn't remove the inner "walls" between each block.

A better technique would be to generate the walls programmatically, and ignore any duplicates/adjacent walls along the way. But I'm going to leave that up to you to figure out

-=-=-
''Load, Next List!''
Posted : Sunday, 22 September 2019, 15:25
zzoom
You could probably do with changing the z axis on the scaleentity pixel, so that the objects look a bit chunkier, I reckon.

Also, don't go overboard with "sprites"
My lazy technique is VERY polygon heavy. Each "pixel" ends up being 12 poly's, and it doesn't remove the inner "walls" between each block.


Thanks for the tips I'm all coded out for today - burnt the candle a little achieving the Cacti as they are.

Increasing the Z-field is appreciated.

Thankyou (still) for inspiring me to code ducks away a while ago.....

[Edit] Nope, ducks away isn't what I called it:

https://socoder.net/?Workshop=Find&Entry=387

-=-=-
Happy coding!