2014-01-12, 03:34 PM (This post was last modified: 2014-01-12, 05:14 PM by StolenBattenberg.)
Well the draw distance can be as much as you want, though at the moment while it's using this rendering engine, I wouldn't recommend going beyond 125 tiles in each direction.
As much info as anyone can give me on SoM, since even the SomEx modified version didn't work is very welcome -- since I'll be able to work on cracking the limitations.
A small an unfortunate update: I won't be working on this for a few months, a big old storm of bad luck just arrived and my hard-drive, which I keep all the source code for projects I make on has broken... It'll take me a while to get spare money for a new hard drive so, damn.
That is bad news, sorry to hear that. Did you backup your data beforehand? Btw will you be continuing the "Lets play ST" episodes? I was enjoying them.
That is too bad. If you are interested, there are quite a few ways to recover data off a bad drive. Also Seagate has made quite a few drives with internal software issues that can make the drive seem dead, but they can be fully fixed with some simple procedures. I have also heard of issues between Intel SATA controller chipsets and some drives that can corrupt a drive to where it shows as 'unformatted', but can be fully recovered with some CheckDisk procedures.
2014-01-19, 11:15 PM (This post was last modified: 2014-01-19, 11:40 PM by StolenBattenberg.)
Ah, I do have a Seagate which I use for programs, but it was the western digital that went... I do have all the SoM 2.0 project files, and the shadow tower series appears un-corrupted. It's probably recording which has killed my hard drive, as it's normally got very low amounts of space (it's a 1TB disk and it'll have around 10-50GB)... I also render to and from that disk, so...
It's actually really funny, because I did expect the Seagate to break first, as it was clicking about a week ago... I ran the CheckDisk thing, and it might've helped since it said it fixed some errors, but we'll see next time I restart my computer.
2014-01-25, 08:17 PM (This post was last modified: 2014-01-25, 10:01 PM by StolenBattenberg.)
A friend has lent me a 80GB HDD, so I'm able to work on stuff but not very well, since the RPM on this drive is stupid...
I should be able to get a rendering demo, which will allow you to view your own objects etc within the engine. I'll also try getting a graphical demo done, which some sexy shader effects like DoF and Real time refraction/reflection water, but we'll have to wait and see.
Updated the OP again, you can find more file format documents, though I'm not sure who'd use them. There's now a part system example, it's pretty obvious on how to use but I'll make a tutorial if you want...
2014-02-04, 04:25 PM (This post was last modified: 2014-02-04, 07:18 PM by StolenBattenberg.)
Alright, so a few new ideas to question and think about are bought into the 'SoM 2.0' plan, here's a few things I've been thinking about relating to it recently.
1) I completely underestimated the amount of map pieces which would actually be possible to have in each map, since I didn't CUBE it... I only thought about it as in one dimension, which would be 2047, but it's actually 2047x2047x511 (X, Y and z) you could have stacked, collision-able levels, and there won't be that weird bug where light is everywhere on the Y/Z.
2) Networking abilities... Now this I'm still thinking about, it would be easy enough to do but I'm not finding much of a use for it in a game like SoM, maybe for online updates etc.
3) A 'compiled' map is another idea added to my work table, I get the feeling having thousands of map tiles in a room, all using separate 'objects' would cause a lot of lag, so I'm going to try and put together a way that will take the data of a map, and turn it into one big map model when the game is compiled, sorta like how part files get written into binary when you're ready to release.
4) A new file to allow something I was putting off, you all having custom map pieces an available feature... This'll be done with a .SET file, which holds the map piece data... I'm not exactly sure how yet because I just thought of the idea an hour ago, and I think about this stuff while I'm programming etc... So far you can think of it as a massive registry for map tiles, which will be unique to each game.
If you wanted a more technical description, it's a massive list, which is loaded into the engine... The list contains link to each tile.prt file, the engine then loads each tile.prt file into an object which can be placed into the world. phew!
EDIT: preview of indev launcher, just trying some styles, i'll also be posting a IDE 'template' of what the SoM 2.0 IDE might look like, since it's gonna allow you to have ALL the tools open at once, rather than just one at a time...
Update week; I might have a demo out later... Depends if I can make all the assets in time. If not later, it'll be sometime tomorrow.
1)[/glow] In the interest of compatibility, the map size has been changed. You get more pieces to play around with, but it might make it a little more restricted if you have huge map sets. It now works like this; You have an 2D array, which is formatted like this: tiles[BYTE, BYTE]. The first 'BYTE' is the map SET, the next byte is the piece within that set. This means you can have 65025 separate map peices, if you use 255 pieces in each slot.
Amount of sets: 256.
Amount of pieces per set: 256.
The reason I've done this is for future improvement on the engine. It wouldn't take me long to make the bytes into a shorts, which would be 131072 separate map pieces. the difficulty comes in registering new map pieces. SoM2.0 will, from now on have a 'TILE.DATA' file. In this you'll have to load each map piece into a set.
[glow=red,2,300]2)[/glow] Now there's a bigger map size; it was going to be 2047x2047 before, now it's 6553x6553. There's no downside to this, and there's actually an upside. It's using exactly the same scale as SoM now, 2 meter (10 pixel). Although you'll still have to use .X, it's not hard to convert.
[glow=red,2,300]3)[/glow] This is going to sound stupid; But because of an idea Verdite gave me with using original assets rather than SoM default when making games, SoM 2.0 WON'T come with a big asset library, it'll come with maybe three map sets and a few items etc for testing. ALTHOUGH... I will have a FREE asset library where people can download more asset packs. I'll also make a small tool when this is done, to merge files like the 'TILE.DATA', so you don't have to manually copy it all.
[glow=blue,4,300]Ramblings of the week
A) With the idea I have for SoM 2.0 growing each and everyday, it's only natural that really awesome and totally out of my depth ideas come to me. Well one of these would be the possibility to go third person... This would probably be an extension of the 'Switch' idea that I stole from SomEx, called 'switch_DS' for dark souls...
B) What's coming from the community?
Pumpkin Paster looks cool, I think that'll be an idea I'll nick and add into the default SoM2.0 framework.
C) irrKlang and irrLicht... Two engines I might use for sound and rendering, the latter being rendering... I'd of used FMOD, but you need a license. Although SoM 2.0 will be free to everyone, using FMOD isn't, and I don't want to restrict the ability to sell games...
This is getting exciting! The set/piece arrangement for Pieces sounds functional; if you arranged it so that each set of Pieces was in it's own folder, it would be quite easy to activate/deactivate sets as needed. That would drastically cut down on the 'tile clutter' and thus quicken the map building process.
