Printable View
Wow, 600 posts already! Scary.
Anyway, just to aid my slightly enebriated memory, me and note are going to synchronise code on saturday "before noon" (yeah right :)).
He's still working on some fundamental changes and I'll be taking it easy with some graphics, sound work and optimizing the blitter.
It feels good to have a fairly solid foundation under us now. This blitter looks like it may abe able to replace our flawed isometric texturer.
That's all for now.
I'm off to sink some more beers.
Wow, this is progressing so fast. I would have thought it would take ages to get to where guys are. Congrats. Keep up the good work. I try to keep updated on this thread, but if I forget to read it for even a day, there are 2 more pages. I end up just scanning for screen shots sometimes. ;)
Great work though. :thumb:
Hehe...yeah, this thread has soon a higher post count then you..:D..It is wØØsys fault that the project grows so fast. He wants to work on it each day. But right now I have to do a big change in the underlaying code. So I have convinsed him to lay off the code for 24 hours, so I can do the changes. I bet I have to work non stop those 24 hours to get it done. Hope I can manage it. Looks good right now, but I am a bit affraid that the code will first run slower before it will run faster again. Because I only have the time to write the shel around the code, and not optimize the functions as we go (I.E write dummy functions in stead of the algorithms I am supposed to write...:()..::)..But as long as the shell is up and running, we should be fine. That way we have again managed to separate our code, so we can both work on the same time. And that would have been a good thing. Looking forward to sync up with you hon'.
Tick Tack, Tick Tack (-29:30h)
- ØØ -
STOP POSTING ON VBF AND GET CODING!!! *whip crack*
You lazy who... :D
Sorry, had to go to the physiotherapy. But I have one Q.
Remember that you tested the speed on ordering the walls from back to front? Did you use an array list then? Should I use an array list? Or is an array list really slow. I know at least that using "foreach" is 50% slower or something then using just "for", but I can still use "for" on an array list, can't I? So any thoughts about it?
Tick Tack, Tick Tack (-25:30)
- ØØ -
An other thing. Are you not storing the width and height of the map anywhere?
Tick Tack, Tick Tack (-25:17)
- ØØ -
I havent been storing that no. At the moment maps are no larger than 50x2x50 metres. I can insert this into the map class tonight if you like based on the actual contents of the map. One thing I can tell you though is that no MapCubes (and therefore wallparts) have negative X, Y or Z coordinates, they are always 0 or greater.Quote:
Originally Posted by NoteMe
We are using Lists instead of arraylists and yes you can iterate through them like a normal array. List in 2005 are type safe and are just as good as arrays in terms of speed, plus they can be resized as needed.
The Generic Namespace is soooo amazing :D
How can a list be just as fast as an array. If you are unlucky a list will be spread all over the place in memory...hmm...well hmm...ok...ehh..
And yes, I need the width and height for the Culling. Would be boring if I guessed that the map was 25, but then it was 10 and then we used 100 times more memory then we needed...if you know where I am heading..:)...but for the moment I will just hardcode 10*10. Then we can fix it later. BTW look how simple it is for you to draw the map right now:
[Removed because of frustration]
Tick Tack, Tick Tack (-25:09)
- ØØ -
Why make 50 calls to DoEvents in the For loop? It should only be called once in a game loop per frame. That way there, the loop will be faster ;)
Quote:
Originally Posted by Jacob Roman
Ehhhhhhhhhh...It is calling DoEvents ONCE per frame..;) And it slows down the system 0.01FPS..;)
Tick Tack, Tick Tack (-24:50)
- ØØ -
Do you have a class for representing a 3d cuboid volume? Something like a 3d version of Rectangle? Or shall I create one? Can you post a copy of your vector class so i can test some code I've just written;
Maps are 25 cubes by 25 cubes in size which equates to 50 metres by 2 metres (high) by 50 metres.
When I store the map size, the size will shrink down from 50 metres to fit the actual walls.
Do you want the map size in metres or in cubes?
Quote:
Originally Posted by wossname
Ehhh..no, I don't have a class for cuboid...what do we need it for? yeah, I can give you the vector class. Shall I mail it to you?
- ØØ -
I think cubes would be for the best. So the first map is 10*10 in size.Quote:
Originally Posted by wossname
- ØØ -
That makes life easier then, as long as you are not calculating metres from it (because cube sizes might change in future builds).Quote:
Originally Posted by NoteMe
In that case I won't need that vector class after all :)
I'll give the map class 2 int members then, Width and Depth if thats ok for you.
OK, but then I have to ask..ehh...can a cube have different size on the same map? If so, then I need it in metres. But if it is a constant for each map, then I just need the constant and the widt, height (num cubes).
Lunch time:
Tick Tack, Tick Tack (-23:11)
- ØØ -
Yeah it'll stay constant throughout the map. But may change from build to build.
I think it is defined as
In either Map or Mapcube class, can't remember which right now. Changing that single constant will change the size of the cubes (width=depth=height at the moment).Code:public Const float DEFAULT_CUBE_WIDTH = 2.0f;
Intro:
I guess the intro screen will just be a form with a nice bitmap on it, I don't think we'll need a menu yet until we start adding features into the game (select level / difficulty and so on). Then when Visualad has got off his lazy bum and made us a theme tune we can have it playing at the same time. This will gives us lots of time to load complex levels, install textures and initialise the enigmatic BlackBox. I've had the idea to make a campaign editor too (very simple in theory, just a class that contains a selection of levels taht the player can battle through in sequence., when one level is won then another one loads up!!!). All we'd have to do is throw away our class instances (texeng, blackbox) an create them with the new level settings. Then we can have another screen come up while the loading happens. this is a job for muuuuuuch later through :D
Also the map files are TINY! even with 10 textures (64x64) the size isn't even near 100kb yet :D this decompresses a bit when it gets loaded but its still not much :) woo0t;
Man.. get rid of that Doevents entirely. Doevents doesn't allow other processess cpu time, it only processess the messages for each window in your app.Quote:
Originally Posted by NoteMe
Wow wow wow....slow down now honey..:D...campaign editor....hmm....it sounds like you are 100 steps in front now. And we never actualy but a hat on this project. How much do you actualy want to make out of this? I have other projects I want to to later on too, not just this. Remember I am a DX man..:)...So I am kind of hoping that this project doesn't drag me into the next century if you know what I mean..:D
BTW, the loading screen sounds fine to me. Just one comment. Maybe it would be cool if it changed from one image, to an other, or if there was a loading bar, or maybe both? Not just ONE static image?
Tick Tack, Tick Tack (-22:05)
- ØØ -
Quote:
Originally Posted by kedaman
It is the best option if we use pure .NET. And other method would be to controll the messages sendt "peekmessage" and so on. But that is a totaly different storry. Using Sleep is an API call. And BTW I don't care about your other processes Keda...you will not be able to run DC++ and DoomSharp at the same time anyway..:D:D:D
- ØØ -
Btw, I haven't bothered reading trough all of this thread. I've been off for a week due to some nasty things happening here with my ISP. Is there's still need for some doom style perspective correct texture rendering that is reasonably fast? I've worked out the clipping and occlusion filtering now, and only need to sit down and put it into code.
screw .NET ;) If I can't use DC++ while running Doomsharp then you have to wait til I download my po.. I mean finished my downloads til I can beta test it and that's going to be a while ;)Quote:
Originally Posted by NoteMe
Quote:
Originally Posted by kedaman
Ohh..sounds nice...I think you two have something to talk about. Wossy have been working on this too:
http://vbforums.com/showthread.php?t=358061
I'll leave it up to you two to decide how to draw. I'm doing the space partitioning at the moment. And writes my shell so wossy can't **** up my code anymore..:)
- ØØ -
Quote:
Originally Posted by kedaman
You are never going to finish your P. So just don't bother..:D...well, we have to wait and see if wossy can improve framerate before we can see if you can run DC++. There is still light in the end of the tunnel...:)
- ØØ -
Hmm.. I'm looking at the code and I'm looking at the pic, and I'm not sure what he is doing, I'm not certain if he is doing it right. First thing is why are those black dots over there, and the other thing is I can't really figure out if there is perspective in that pic.Quote:
Originally Posted by NoteMe
Wossy: If you read this post, can you render a striped or even better a checked texture?
He can change the points as he want in that picture. That is what I know..but no idea if the texture is smaller on the right side then on the left side.
The Dots I guess is because of rounding errors or something...no idea...:)..but that is not a big problem anyway...
BTW have you speed tested your algo keda? Can you check how many FPS you can manage to get? Or even send the app if you don't mind?
- ØØ -
I hope so, this is certainly a fun project, even if you are doing it in .NET ;) You could still benefit a lot from having the main loop coded in ASM ;)Quote:
Originally Posted by NoteMe
The previous algo got up to 50fps by rendering 20 of those walls. My new algo will run faster, and in addition it will filter out wall parts that are not visible due to other walls being in front of it, so even if the screen is filled with a lot of walls, it could hardly go any lower than that. Mind you i'm running it on a 1,2Ghz Athlon. I have to check out why my cpu speed has dropped, but I haven't had the time yet.Quote:
Originally Posted by NoteMe
Quote:
Originally Posted by kedaman
Yeah, everything can be done faster in C++ and ASM, but it is somewhat the point of this project NOT to use anything else then C# and .NET. I think it nearly does the project even more fun.
You should join a project once..:)
- ØØ -
That's odd with the black dots btw, you're definitely not doinf it the right way if you are leaving black dots, you're suppose to map the pixel coordinates to texture coordinates no the other way around.
Quote:
Originally Posted by kedaman
Wow wow wow...that is incredible fast..well it is in C++ though. So we can't expect the same speed here anyway...but still. It is really fast.
What method are you using for the culling? Z-Buffer? W-Buffer? Querrerying? I am interested..:) Give me the details..:)
- ØØ -
Maybe ;) But I'll probably do only bits and pieces here and there when I get time ;) And the ASM will run a lot faster even than C++ so, it might be possible to fit in the ASM part in C# using fake pointers to a block of ASM code you put in an array in C#, and api calls to callwindowproc and copymemoryQuote:
Originally Posted by NoteMe
Quote:
Originally Posted by kedaman
As usual I belive you..:) Wossy is not going to be able to work on it before after hours today though...:(...but hope he can drop a comment on it or two before that.
BTW I shouldn't belive you anymore...for some reason your view to screen coordinate calculation didn't quite work. It stretched the textures. So if the window was wider then it was tall, then the thextures where wider then tall too. but I have fixed it now though...But I should stop trusting your blind folded..::D
- ØØ -
But we are not cheating...this is PURE C# and PURE .NET...the ASM stuff can be saved to a later project...do you hear me..:D:D:DQuote:
Originally Posted by kedaman
- ØØ -
I've not done any culling yet. I'm planning to use occlusion culling in the final algo. The other algo used a lot of floating point calculations, but I'm not sure how fast it will be than that, because the innermost loop was quite optimised, as it uses the same technique as my new one, having a constant depth, i.e. doom style rendering.Quote:
Originally Posted by NoteMe
damn.. you probably didn't apply it right then? :DQuote:
Originally Posted by NoteMe
Quote:
Originally Posted by wossname
??? Where are you making that list? In Form.cs I can only find this:
Primitive[] walls = null;
hence..maybe you forgot to make it a list? Or?
- ØØ -
ok ok, but in the next project you can have some help from me ;)Quote:
Originally Posted by NoteMe
Quote:
Originally Posted by kedaman
Yes yes yes I did..:D...it was your calculation that was faulty..:D
- ØØ -
Quote:
Originally Posted by kedaman
Good, I have a very very interesting idea for a Demo...I will start on it right after we have finished this one...:)
- ØØ -