 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by Guy Perfect |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
| User | Post | ||
Guy Perfect                    Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Ah, I see. It's not a matter of thinking up ways to do things; it's a matter of not knowing how to do things in the first place.
Yeah, I'd say the first thing you should learn about is how to use buffers. In C: int BuffSize; char *Buffer
BuffSize = 64; Buffer = calloc(BuffSize, 1); // Do stuff here free(Buffer); In BASIC: Dim BuffSize As Long, Buffer() As Byte
BuffSize = 64 ReDim Buffer(0 To BuffSize - 1) As Byte ' Do stuff here Erase Buffer In both examples, the Buffer variable works as a raw byte array. Buffer[0] is of type char for C, as Buffer(0) is of type Byte in BASIC. Both arrays have a lower bound of 0 and an upper bound of 63. In the page I linked in my previous post, I was rejoicing that I was able to use any kind of data I wanted--an array of user-defined structures in the example--inside the block of memory declared by the program. You can't do that in BASIC. What you have in BASIC is an array of Byte variables. No more, no less. In C, you can do whatever you want in there with pointers. In any case, the in-memory buffer is your best friend when working with file data. Depending on the file (say, less than 5MB), you can usually load the whole thing into memory, but larger files (media files, databases) may need to be accessed little pieces at a time. While it's different checking things like "if (Buffer[Pos] == Search[0])" is certainly a different way to go about a routine, it gives you far more control. All-in-all, I think you'll be fine with C or C++. You already know how to use them, so I'd say it's best to stick with it and expand your base knowledge. Learn how to use buffers, and I'm sure you'll come up with many applications to use them. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| I'd like to reiterate that VB needn't be used for simple things; it's capable of much more in-depth applications as well. That link I posted a few messages ago is to a level editor for an N64 game, complete with 3D preview using OpenGL.
Without any intention of glorifying myself (and believe me, it's gonna sound like it), I can make the observation that most of the programmers on this site likely don't have the required expertise to make software of the such regardless of the language they're using. Since it was done in VB, I think that goes to show a lot for what VB's true worth really is. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| You can break execution at run-time within the IDE by using the Ctrl-Pause/Break key combo. Works well with infinite loops. A holdover from the QBASIC days. | |||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Mr. Graham certainly describes very well the typical mindset of a programmer. I've seen through experience that programming languages are kinda like political ideals... people defend theirs tooth and nail even if they have no idea what the other ones are like. And as such, since Grandma and Grandpa were associated with a specific one, there's no need to even consider the existence of the others.
It depends on what your needs are. If you want a programming language that can accomplish just about any conventional task and is easy to work with, then Microsoft Visual Basic is a viable candidate. If you want something that can compile on other operating systems, then VB is not the candidate of choice. If you don't need your programs to run on other operating systems, then VB is a viable candidate. Originally posted by Cellar DwellerIn the world of debate, this comment is classified as what is called prejudice. It's a judgemental statement that is almost always prompted by an affinity for an alternate point of view and is typically underinformed. I don't know your Blub, Cellar Dweller, but unless you were on the design committee at Microsoft when designing Visual Basic, I don't think you'd be able to conclude that it was designed for those "who barely know how to program." Again, I use the example of the F-Zero X level editor. I used Visual Basic and a Microsoft-provided, VB-targeted type library to work with OpenGL. If Microsoft didn't intend for VB to be used by those who are proficient in programming, then they wouldn't have given it the capabilities they did. Microsoft holds true to one of the original concepts of BASIC: to protect the user from the operating system. As such, they never implemented ways to manipulate pointers, but they certainly provided a way to access them. The undocumented VarPtr() function and AddressOf operator were made for that very reason; such that VB programmers will still be able to use memory addresses in their programs, even if they can't access memory directly by that manner. I also know through experience and by example (see above) that pointers and bit shifting are not required for most things. If you don't need them to make a 3D editor for a Nintendo 64 game, then they must not be significant weaknesses of the language. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
Oh! Spambot! I recognize those!  |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Adobe Paint... Just think of the ramifications! Ready your mob adornments! | |||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| This thread is uncalled for. It won't be long before a "Let's Rant About BriGuy92" thread surfaces. | |||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| "Let's" is the contraction "let us." "Lets" is analagous to "is letting." | |||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| When I absolutely need to wake up, I schedule a task on my Windows computer to run a sound file at the designated time. I just pick one of the tunes out of my music library and set it to play, configure the media player to repeat it forever, and set the speakers at a volume such that I could hear it from any depth of slumber. And since I have to get out of bed to get to the computer, it's as effective as can be as an alarm. | |||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| I've just coded up a simple LZ compressor in C that searches through 64KB of data looking for matches. It's a fairly standard app that looks through the backbuffer for the next byte to be encoded, then finds the match length when it finds one. After finding the longest match (by seeking through the entire backbuffer), it encodes the data appropriately to save space.
It works great. The 64KB buffer compresses a 740KB, 24-bit .bmp image to 175KB, where a ZIP compression (which also adds a Huffman compression to the mix) only gives 148KB. A mere 30KB difference with ZIP ain't too bad, right? Thing is, ZIP takes a mere instant to compress, and my app takes upwards of a minute! ZIP does more in its round than my app, but mine takes significantly longer to encode. What kinds of optimizations are available? Comparing multiple bytes simultaneously by using larger variables? Keeping track of what bytes are in the backbuffer such that bytes that don't have significant matches won't be checked? It's kinda bugging me as to how to improve performance. It's not too important that I do, but I'd like to know how if anyone has any tips. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| If I wanted source code, I would have asked for source code. zlib is free source, which is faster and offers better compression for the most part. But that's not what I want.
I specifically want to optimize the code I conjured up all by myself. After all, you can't improve in your art if you just slap in someone else's work. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Like Young Guru said, collision by its very nature applies to distance. You can do collision checks of any shape you want fairly easily so long as it is either circular or a polygon. Just check for the distance from each of the vertices, as well as the edges that connect the vertices. I've attached an image to better describe what I'm talking about.
(edited by Guy Perfect on 01-09-07 09:02 PM) |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Like Ailure said, I discourage use of proprietary languages just 'cause they're subject to change against your will. That includes Java, which is heading towards open-source and will inadvertantly spring millions of variants.
Sadly, only Full BASIC exists as a standardized variant of the language, and support for it is minimal. I haven't done much research on it, so I can't guarantee that you'd be able to write games in it that utilize hardware considerations like OpenGL. C and C++, on the other hand, are supported by all major operating systems and said systems also provide support for OpenGL. This means that using these languages, you can write programs that use a common syntax, and only include small bits of code to set up viewports on multiple systems. If you're set on using BASIC, I suggest FreeBASIC, which typically compiles with the power of many C programs. It has a simple, procedural syntax which is basically (no pun intended) just as functional as C, but with different syntax. It is, however, proprietary. I dropped my personal support for this one when they started juggling features whimsically; adding and removing them on a moment's notice. I recommend C, because people seem to have left it alone over time. It became an ANSI standard in 1989 and ISO in 1990. Hasn't been touched since. C++ is more popular, but each time it's updated, it becomes sloppier than the previous version (subjective comment, of course). C is well-supported, optimized, functional and an all-around good language to use for just about any need you might have. It's also very simple, which makes good and fast compiled executables, which is a bonus for game development. |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
Originally posted by TanksI made a level editor for an N64 game, but I've never hacked an NES game. In fact, F-Zero X was the first ROM I ever hacked. Go figure. (edited by Guy Perfect on 01-18-07 06:29 PM) |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Like just about any ROM, the programming tends to be at the beginning and require little space; and resources at the end composing the remainder of the data. Corruption is still a viable option when attempting to locate resource data in N64 ROMs; it simply won't help a lot with programming inquiry. | |||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| Today - End of Time
Scheduled Time ~ Scheduled Time: JOB101 - Work |
|||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| DS ROMs are single files, but they include a header with a file table pointing to offsets in the ROM and associates them with filenames. Other things in the magical header include various checksums, game name, game icon (for the boot screen), etc. | |||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| If you're using a Form or PictureBox as the source of the DC, it'll be slow. Use the GDI to create an in-memory DC and work with that. | |||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| OpenGL is much easier to use from VB than DirectX. | |||
|
Guy Perfect Since: 11-18-05 Last post: 6302 days Last view: 6301 days |
| ||
| The favorites icon thing was introduced as a feature of Microsoft Internet Explorer which, at the time of introduction, requested a favicon.ico from every site the browser visited. It has since become standardized, and is described by the following tag in the page's header:
<link rel="shortcut icon" href="http://wherever/blah.ico" type="image/vnd.microsoft.icon" /> Alternately, image/x-icon may be used. This is the official way to do URL icons nowadays, so DarkSlaya was not "completely wrong" when he posted that information. |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
| Acmlm's Board - I3 Archive - - Posts by Guy Perfect |
