The yellow one is Psy =P
Z.
Printable View
The yellow one is Psy =P
Z.
OI!!
Ladies, leave it out :P
Zaei, i want a mouse/keyboard style fly FPS camera for the 3D which i think i have.
The ortho views are the hardest
Do a google search on spherical coordinates. You will find them to be a bit easier to use when trying to find a direction vector to create the camera with.
Z.
hi
I have downloaded the Demo but it does not seem to work I get this massage:
Title: "microsoft visual c++ debung library"
massage:
"Debung error!
program" &app.path&"\divloader.exe
damage: after normal block (#217) at 0x03B4B68
(press retry to debung the application)"
I really do want to test it
There is a memory overwrite happening somewhere, but to be quite honest with you, I dont know where or why, and I dont plan on finding out. That demo is just too old. We should have a new demo out soon, so wait for that =)
Z.
Im having a bit of fun over here... writing a pathing map generator... lots of fun!
Z.
Zaei i think i know what they are. Didn't look em up coz i have used asimilar system in OpenGL. its just alot easier coz all u do is like gluLookAt(eye, look, up); but in direct x there is a load of other bits.
i think it needs seperating coz u setup the view once then u chane the view position whereas u have it all in one function which is called every frame.
gimme a few days n i shud have some of it fixed up - busy over here at the mo.
With D3D, its just D3DXMatrixLookAtLH, same parameters, and then you just SetTransform(D3DTS_VIEW, ...), and you are done.
Z.
Guys, I get the feeling I haven't actually done anything in a while, and this is completely true. I can't believe that I'm just sitting here....
Well, to put it to a point, I'm getting to work :) Expect the MapGen DLL by the end of the week.
Ive got a project for you after that =). I need a pathing map generator, that will take a 2^n heightmap, and generate an appropriate pathing graph from that map. First, a node should be placed on each tile, and then, based on the heightmap, connect the nodes together, as long as the slope of the terrain is less then some threshold. Once that is done, the map needs to be optimized (so that there are fewer nodes on open flat areas.
More details later =).
Z.
Great, this is good, I need the work to do (I should do something else than give others work, eh? :rolleyes: ).
Psy, give me an estimate on when things will be wrapping up with the map editor.
Zaei, have you and Psy agreed on a common file format? If so, your next project is to implement this in the engine.
Also guys, when you're coding things, from now on ask me if you have any questions. Jorj and I had a very set view on what we wanted ToW to look like at the end, at I'd appreciate if you guys observed this as well. As long as you're doing reusable, dependant code, all is fine, but if Zaei has told me enough about how he's implemented things, something tells me that all the customization will be in the divinity script.
Just keep going, and remember our hopeful christmas release. Here's a list:
- Map editor done, random map and terrain generators complete.
- Map loader implemented; full unit control.
- I doubt we'll have time for any AI this time around. Let's try for just slaughtering wandering creatues >=).
- Load a DIV file to play a game (the MOD system).
More will come to mind, just continue on and we'll be fine.
No, we havent agreed on a file format as of yet. I got the nifty idea earlier today to simply save the files in whatever format works, and then build serveral tools that will essentially compile all of the separate file types into the final map type.
Z.
So, ala. Half-Life vs. ala. Unreal. Hmm. Half-Life styled compilation allows for more error-checking and optimization outside of the code, which, you must admit, is pretty much useless with an RTS.
Useless? Hardly =P. Good optimization of the pathing map, for instance would speed up AI and movement calculations, etc. Heck, it would even allow compile time AI information to be embedded into the map file. =)Quote:
Originally posted by Sastraxi
So, ala. Half-Life vs. ala. Unreal. Hmm. Half-Life styled compilation allows for more error-checking and optimization outside of the code, which, you must admit, is pretty much useless with an RTS.
Z.
Well, for pathing maybe, but I was talking more along the lines of the traditional VIS program. Besides, optimization wouldn't take long at all, and could be done during saving.
The real reason is simply ease. Psy can go and save in whatever format he needs, and I can write the engine to use wht I need, and then write a simple converter to build an engine map file from Psy's map files.
Z.
I hate that way of doing things, I must admit. It might be OK if the compiling was only half a minute or so, but no more than that, OK?
Ill be amazed if it gets that high. The other advantage is that if people hate our tools, they can make thier own =).
Z.
Yes, but they won't hate our tools, hint hint ;) As long as every file you create from the maped is runnable (like BSPs), I'm fine. It just can't be in a temporary format, like MAPs or RMFs (worldcraft ;)). It would just feel more like an RTS and less like Linux (;)) if we did it this way, ok?
Zaei im getting there with the editor. hopefully will be done soon.
i got the heightmap done. i got the tilemap done. ive almost got the views done (3d).
i then need to work out how to apply the tilemap to the 3d wireframe.
talking of compiling... i actually added that feature to the editor before it was mentioned here heh :)
im probably gonna save the heightmap as a 24-bit bitmap, the tilemap as an index of tiles and an indexarray.
Why 24-bit? Do you really need 16 million different heights? :)
It would allow him to use a graphics program to do some kind of manual editing of the map =).
Its all in the interests of expandability, Sas =).
Z.
No, really, I don't see why. Use whatever bits you guys need, and then have a convert-to-BMP function. I wouldn't think the heightmap would be directly editable Zaei (I hope not anyway!).
Alright Sas, however you want it done =). Its just not worth arguing over.
Z.
Sas, i dont wanna seem a ***** here but i think how Zaei and i are thinking thngs should be done is best, from a coding point of view.
The editor creates an index for the tilemap and a 24-bit bitmap file.
This then allows me to make it (which i have done) so you can import tilemaps and heightmaps into new maps. once your are happy you click the compile button and it removes all the extra data from the bitmap and saves the needed heightmap values along with all the other data. Thus the finished levels are not easily edited (you would have to code a loader seperator etc) unless u have the original data.
It is loads of extra work to convert it out of the standard image box's bitmap format to a single height value and back when it wants to be edited again.
this also allows us to just call upon a dll with the compile code in which does it.
I just think its a whole load better. i mean, hey we could put all the texture data into the map but then it wud be no good to use them in other maps unless u had the original.
Your saying about high compilation times but when u look at such things as creating a UT map you have to do loads of generating of lighting etc which is that quick. to cnonvert some data, stick it all together in a file isnt going to take that long.
Just my view but i think its backed by Zaei too.
Psy, do it both ways. You know, a Save option, and an Export option. That would give the greatest flexibility, as well as allowing ease of use.
Z.
heh, save and compile in this case.
Compile - Final single file 'the map'
Save - Individual bits for editing.
I have a import feature already built in.
Okay, fine. But how about this:
1. Compile - Saves to TOW Map format.
2. Save - Saves to working map format.
3. Export - Exports the little individual pieces for editing.
4. Import - Compiles little pieces so that you can Save or Compile.
I do like the idea of non-editability though, its just that if someone wants to distribute the source of the map, its going to be huge (file-size wise). So, we make an alternate save option that compresses the output (ex. PNG compression on the heightmap, zLib on the others, and yes I know PNG uses zLib for the most part ;)).
Sounds good =).
Im working on billboarded lines at the moment. Also have some ideas on collision detection =)
Z.
Sas i changed the views up to how they should be. theyre all working off the same variables at the moment though im working on giving them their own ones so they move independent. Then it will be going nice.
I have got the opening/saving of files sorted more although im gonna have to re-write some code to get that going properly.
http://caunt.8bit.co.uk/work2.JPG
Psy, looking good. Those views didn't look true 2D to me - but you said those were coming, so thats OK. The map looks good to me at this time, but how does it run on your computer?
Looking very good, Psy =)
Z.
So, tell me what you guys think =)
http://www.vbforums.com/attachment.p...postid=1268948
Z.
Luke, I am your tree... :D
Is that collision detection? Well, it looks good. And the terrain around it looks extra-spiffy too.
Can we get a zoomed-out shot?
Good, Zaei!
No, thats just a pretty line =PQuote:
Originally posted by Sastraxi
Luke, I am your tree... :D
Is that collision detection? Well, it looks good. And the terrain around it looks extra-spiffy too.
Can we get a zoomed-out shot?
Good, Zaei!
Zoomed out shot? Sure.
Z.
Here ya go... Zoomed out. Lot slower this way =).
http://www.vbforums.com/attachment.p...postid=1269051
The line is not completly finished yet... Still have to figure out the width thing... but I shall get it =)
Z.
Oops, forgot the picture.
Z.
The line is looking really nice =). Lightning, anyone? =)
Z.
Sas true 2D is on its way!!
Zaei, looking pretty sweet. may i ask what the black lines that are vaguely in the top left area is coz ita kinda weird.
Terrain is looking sweet!!