snarfblam

Use the modulus operator. Dim I As Int32 I = 10010 MessageBox.Show((I Mod 100).ToString()) ' Displays "10" int i; i = 10010; MessageBox.Show((I % 100).ToString()); // Displays "10"

The static Sytem.IO.Path class is good for elementary filename/path manipulation System.Windows.Forms.MessageBox.Show( _ System.IO.Path.GetFileNameWithoutExtension("C:\\Filename.txt")) ' Displays "Filename"

My bad. On the whole, I guess I was wrong. I didn't check the BMP for compression, but you are right, the RLE compression is a big space saver. I will mention, though, that you cetainly could use a lower bit depth than 8 bpp. Specifically, using Photoshop, I saved an image as a 4 bpp GIF with no visible quality loss, reducing it from about 100 k to about 50 k. It is also worth mentioning that the GIF format has built in transparency, saving you an intermediate step (at run-time) of applying a transparency key. I was able to achieve similar results using a PNG. With Adobe Photoshop CS you could probably get even smaller files with a PNG than I did (despite common misconceptions, PNGs compress smaller than GIFs of comperable quality, but Adobe Photoshop versions prior to CS have substandard PNG compression). I know I tend to offer a lot of criticism, but I do so strictly for the purpose of being helpful and informative. Clearly you did put a reasonable amount of thought into filesize, and the end product already looks pretty good. I just wanted to give you some tips to help out.

I didn't play the game, but I'm gonna share my opinion of what I can see here and in the one RAR I downloaded. I certainly would have tried for a more compact approach, but regardless of filesize, it certainly looks good. If this is were to be distributed on CD the file size wouldn't be a problem. Over the internet, though, there are at least two simple thing you could do (maybe you were going to anyways): One thing would be to use a compressed image format: GIF or PNG. Also, reduce the amount of "wasted space" in your images (although GIF or PNG would minimize the impact of this "wasted space"). Crop only the used rectangle in the image, removing large regions that consist only of your transparency key. When you draw the image, draw it at a specified offset. This would be a relatively small effort to drastically reduce the physical size of your images, resulting in faster GDI+ rendering, and depending on format used, you may get drastically smaller files too.

It is worth mentioning that if the user has the welcome screen disabled or they are running windows NT/2000+ (anything NT except XP) LockWorkStation will do just that: lock the work station.

If we are using DirectX, there is no problem using a single texture. On the other hand, GDI+ can scale, skew, and rotate images. It can not perform the distortions necessary to create the effect of a perspective. Besides, doing it the pre-rendered way is old school, and cool, and stuff. It's got more EOB spirit.

First of all, experiment and find what works for you. Secondly, my comments on EFileTahi's preferences. Since that is what works for him, by all means he should keep doing that, but there are some points you should consider. [1]Commenting everything: Many people would argue that too many comments are a bad thing (though not as bad as no comments). It takes focus away from what absolutely must be commented. Use descriptive names and code so that intent is usually apparent. Keep Plausibly's and mskeel's suggestions in mind: comment on what code does (or better yet, why it does it) only when it isn't obvious from its surrounding context. Maybe comment everything for starters and when you go back later, you will discover which comments you find necessary, and which ones you don't. [2]Regions on functions: Functions are collapsible anyways. My suggestion would be to add a descriptive comment for each function and collapse the function. [3]Long object names: Do what works for you. If short names adequately describe a variables purpose to you, use a short name. If a long name is necessary, by all means use a long name. (I keep my names shorter because I find that I have an easy time remembering what variables do, and long names clutter my code and hurt my head. That's just me.) [4]Prefix Variables: Many poeple argue that Hungarian notation is a bad thing for a few reasons. Yes, it helps identify what the type of the variable is, but it can also take from the readability. This might apply more to VB, where you often get statements that are almost gramatically correct English. Also, people who don't like Hungarian notation argue that the type should be implied by the purpose of the variable, which should be evident from its name, i.e. instead of bContinue, use ShouldContinue, or WillContinue, or CanContinue. It not only implies that Continue is a boolean (it wouldn't make sense to store WillContinue as a string, integer, etc.) , but also more accurately describes what that boolean value indicates. This doesn't mean that prefixing your variable is a bad thing. It just means that some poeple prefer a different coding style.

Just a quick question: Say you simulate less than a 90 degree field of view, displaying four tiles deep, and you use a different image for each element (i.e. floor in occupied square, wall on left, wall on right, three images for the floors in the next row of tiles, and two or four walls for that row, five images for tiles in the next row, all the ceilings, etc.), that would come out to at least fourty images, no? Say you want to make it interesting and add ten or so types of walls (let's say stone, like the example image in the first post, add cave walls, cement walls, tile walls, you get the idea), that would become about four hundred different images for the walls. Do I have the right idea? If so (and I'm not sure I'm right), you might want to consider something like this: First of all (and you might have already considered this part), since every tile will usually have a floor and ceiling, start rendering every screen by drawing an image that contains the floor and celinging for all the visible tiles (sample1.gif). Then you draw maybe three images for walls: those for the row of tiles extending straight forward (sample2.gif), another for the next row out (further left/right), and maybe a third. Using precalculated X coordinates from the simulated 3D projection (sample3.gif) you can cut the wall images into vertical strips for each tile (sample4.gif), drawing only certain portions with an overload from Graphics.DrawImage for the walls for different tiles. Use a similar technique for the walls that will be facing you. This would cut you down to six or seven images per texture, and produce images along the lines of sample 5. (Sorry about all the long post and five attatchments.)

You may also want to research dynamic event handling (look up AddHandler and RemoveHandler) and consider storing dynamically created controls in some sort of array or specialized class so that you can access them in an organized and logical, yet dynamic, manner.

Depending on... something (I don't know what) swing can use XP styles (my NetBeans apps used Xp Styles), but yeah, I've seen some ugly Java apps. And C#/Java aren't based on C++. They use C-style syntax and are object oriented, but these aren't unique to C++. The biggest difference between C# and Java would probably be the standard libraries. As far as C++ being "fake object oriented," I don't know if that is the best way to put it. It might not as traditionally object oriented, and the exectuables may not be self-describing (a lack of type definition metadata), but within a single program I would say that it is possible to write code in a completely object-oriented manner. You have your encapsulation, inheritance, data-hiding, polymorphism, yada yada yada. I'm not sure that object-oriented implies garbage collection or a lack of pointers, but if there are any other enormous differences, they wen't over my head. And just a note, this thread was over a month old. I personally don't mind, but the posting guidelines do ("Threads that have been inactive (no new posts) for one month or more should be considered archive-only and should be left alone (except by the thread starter).").

Okay, we have too many geeks beating dead farm animals here. Arguably, one could say that the Then and End If keywords equate to curly braces since they surround the code block to be executed conditionally. Alternatively (this is my take), one can argue that while the End If is completely analogous to the closing curly brace, the opening curly brace is only implied. The Then keyword is, to an extent, a relic from a time when the only If statement was a single-line If statement (though the Then would still be a necessity for a single-line If statement). Since in VB the conditional expression isn't required to be surrounded in parentheses, the Then is necessary to syntactically separate the conditional expression and the conditionally executed code statements, hence it might be more analogous to the closing parenthesis of the conditional expression (this is consistent with single-line If statements too), or possibly the combination of the closing parenthesis and the opening brace (the opening parenthesis would be implied). Here is one interpretation of the syntactical analogy: Multi-line C# VB -------------- if( If <conditional expression> ) { Then <conditionally executed code> } End If Single-line C# VB -------------- if( If <conditional expression> ) <code> Then <code> [/Code] Take that, you effing horse.

Diesel, take it easy. Regardless of whether you are (or anyone else is for that matter) right or wrong, being rude or insulting isn't helping anyone program anything. Good::-\ Bad::mad: See? The code you posted is in QBasic, and there are 92 files. It is probably not exactly trivial to a .Net programmer. It would be more than helpful if you would clearly explain what about the rendering engine you would like us to understand.

Thats because half the declaration seems to be in VB6 and half seems to be in VB.Net. I'm also kind of confused as to why a return parameter is being passed as a StringBuilder instead of a string, unless StringBuilders are simply more flexible in their marshalling. Try: Private Declare Function mciSendString Lib "winmm.dll" Alias "mciSendStringA" (_ ByVal lpstrCommand As String, _ ByVal lpstrReturnString As String, _ ByVal uReturnLength As Int32, _ ByVal hwndCallback As Int32) As Int32 or Private Declare Function mciSendString Lib "winmm.dll" Alias "mciSendStringA" (_ ByVal lpstrCommand As String, _ ByVal lpstrReturnString As System.Text.StringBuilder, _ ByVal uReturnLength As Int32, _ ByVal hwndCallback As Int32) As Int32 The unbalanced stack happens because the declaration you are using has two longs (VB6 Int32 versus VB.NET Int64), resulting in an extra four bytes of data on the stack.

Either that or this: if ((objType.Attributes & TypeAttributes.Abstract) != TypeAttributes.Abstract) { } I guess I'm just to lazy to paste my code in a code editor to check for errors. Maybe I should add a disclaimer in my signature that none of my code is tested...

Oh, no doubt that DirectX would be easier. I'm sure that the GDI+ rendering would be extremely slow and it would take plenty of work to make GDI+ to something particularly tridimensional. I was just wondering if it would even be possible.

You are correct. And is bitwise and logical in VB. The only differences worth mentioning are that C# doesn't need the Then, and the different operators: And becomes &, = becomes ==, and Not becomes !. if !((objType.Attributes & TypeAttributes.Abstract) == TypeAttributes.Abstract) { }

I'm sure you can put a little more effort into it than that. Are you trying to accurately describe what a texture is, or are you trying to discredit me? That is a definition of a texture in terms of 3D models, specifically from their article on texture mapping (a technique of texturing a 3D model). It is taken out of context. If you read their article on Bitmap Textures then practically any raster image at all would be considered a texture. The following is the Wiktionary definition of texture, in terms of graphics:

Whether the walls are defined as polygons in a d3d buffer or a gdi+ destined tile-based map, they are being applied to a 3d or pseudo 3d environment. Just because we aren't using a hardware accelerated, polygon based engine doesn't mean that they aren't textures. That's just my two cents. And this isn't quite the same as Wolfenstein 3D. You move a whole tile at a time, and turn ninety degrees at a time. The rendering isn't real time. The graphic result might resemble Wolfenstein 3D, but the underlying engine would be quite different. And just out of curiosity, is it just me or is anyone else disappointed that there is still no implementation for a four point list to draw distorted bitmaps? It sort of limits you in terms of graphic manipulation.

I'm not sure the idea here is to pay for a graphics engine (or wrapper for a graphics engine). Besides, there is a free managed wrapper for DirectX. If you are using DirectX, you could create the entire environment, and just move the camera. If you are using GDI+, as far as calculating whats visible, you would want to set a maximum draw distance (for example, the image you attatched has a draw distance of four rows of map tiles, including the occupied tile). Player's direction would have to be accounted for. You would want to draw from back to front. Depending on the emulated field of view, you will need to draw a certian number of map tiles in each row, increasing as you get further from the user. A 90 degree field of view would require that one tile be drawn for the occupied row (which would be the occupied tile), three tiles in the next row back, five in the next row back, and seven in the fourth row. I don't think that something like this would really require a game loop if programmed in GDI+. Those are more like tips than a general plan for the engine, because (especially if you use GDI+) the overall engine is up to you and shouldn't be too difficult. It's the rendering that would be the challenge.

You record the mouse position on mouse down. You compare changes in the coordinates on mouse move and size the control accordingly. Alternatively, you record the postion on mouse down, draw a sizing rectangle on mouse move, and size the control accordingly on mouse up. Not particularly tricky. The coding part is up to you, though. If you run into any problems coding, we'll be glad to help.

I personally wouldn't overload the == operator. Operator overloading isn't my style anyways, since it doesn't do anything but assign function calls to operators, it is really just syntactical sugar. (What is it at the IL level? Are the functions marked by flags? Or do they have special names like contructors?) But I can think of a dozen cases where you might want to overload the == operator on a class. For instance, if a class is instantiated with data loaded from a file, and you want to compare different instances for duplicate data, or if you have a class related to something like a domain name, registry key, or file, and want to check if objects refer to the same domain/key/file/etc. I can see people doing it left and right, and then shooting themselves in the foot when they unwittingly call the == overload because they are trying to check for equal references.

You mean what if they are like me? I would assume that they are using the most current version, and I would provide code examples in the language most comfortable to me that we have in common. Even without the confusion of which version a user has, how have you determined which language to use in the past? Sometimes I gave code samples in both VB and C#, and sometimes I said "here is some vb, if you use C# im sure you can manage the translation" or vice-versa. I personally won't hesitate to say "use so-and-so class, but if you are using version 1.1 you are out of luck." Of course, I am not aware of every single difference between versions and the time will surely come when I don't make a point of which versions a feature is available in or I tell a user of a particular version to use something that isn't available to them, but I doubt it will be common place. No, you shouldn't have to check a profile each time you post, but I was only recommending doing so as a temporary solution. I don't know if it is possible with VBulletin, but it would be nice if we had some simple icons that we could put next to our names or below our avatars that indicated what language(s) we used primarily. To me that would be an ideal solution.

Oh.. my confusion stems from the fact that I didn't realize that operator overloads were static (can you tell that I've never overloaded an operator before?). I suppose overloading would be the appropriate term. I'm kind of weary of the fact that operator overloading can change the behavior of the == operator. In C++ to compare for equal reference, you can compare pointers or addresses, but you must dereference a pointer to use the overloaded operator. In other words, the reference itself is a different type than the class and the operators function differently on these different types, hence you are adding functionality, but not modifying it, where in C# you can introduce ambiguity since you can overload the operator that previously compared the references.

Here is the difference. When I tried it, I had the control automatically display the context menu by setting the control's ContextMenu property to my context menu. In your code, you explicitly call the ContextMenu.Show method. This shouldn't make a difference, but appearently it does. If possible, set your context menu to be displayed automatically by setting it as a control's context menu (don't know if this is a 2.0 only feature or what).