(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
 Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album 		06-01-24 12:21 PM
Acmlm's Board - I3 Archive - - Posts by Cellar Dweller +
Pages: 1 2 3 4 5 6 7
User Post
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 12-15-06 04:25 AM, in Link
forum.php?id=00 is what I use. FORUM DOUBLE ZERO

I remember that during much of the second incarnation, it was possible to post in non existent threads. There used to be a zero thread that could be accessed with thread.php?id=00 until Acmlm added an zero thread to the database and closed it. Later a bunch of people started posting in other non existent threads. I had the first post in thread 10000 weeks before it was started, but before then the post was moved to another thread. When Jesper found out people were posting in such threads, he changed thread.php to not show them. At that time, nothing was done to newreply.php, so people could still read and post in the non existent threads for a while longer.
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 12-15-06 07:57 AM, in Memory Buffer/Array Overlays Link
The reason I brought up the file stuff is because structure overlays are a popular but often unwise technique for handling data that originated from or is destined to somewhere outside the program. Also, the example program did write to a file.

I wouldn't think a double fclose() to be safe. The fact that file streams are pointers suggests that they point to data on the heap. The first fclose() free()s the FILE structure, and if an attempt is made to call fclose() again, the program would probably segfault or cause a double free(), which would probably cause a segfault later.

Not too long ago, a program I was working on had a wierd segfault bug that was driving me nuts. By using Electric Fence I found out I had a double free() in it.
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 12-24-06 06:34 AM, in Let's Rant about Visual Basic! Link
Let's see, VB is Windows only, does not have bit shift operators, doesn't have pointers, and is designed for people who barely know how to program.

Paul Graham explains very well how programming languages can vary in power when he makes his case for Lisp being the most powerful programming language. I thing that the following paragraph explains it well:
Originally posted by Paul Graham at http://paulgraham.com/avg.html
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
I think that those who have used any dialect of BASIC and then used another language will clearly understand the above paragraph.

Originally posted by Ogama Dobe
VB blows. We signed up for this class in the hopes that we would learn how to make games. Yet we have had no promises. No nothing. We did nothing of the sort in QB either.


Most practical programming classes are aimed at students planning to program in a business environment. VB is designed for programming simple one off business apps by marginally skilled programmers, so I would not expect to learn about programming games in a VB class.
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 12-27-06 12:16 AM, in Super Mario 64 Hacking discussion thread - READ THE FIRST POST BEFORE POSTING! Link
This should help move SM64 hacking forward.

I got Mupen 64 compiled and working under AMD64. I removed the dynarec and changed a bunch of size sensitive variables to use types from stdint.h, along with a bunch of other little changes. I intend to release it, earler if anyone is interested.(GTK/*nix only. The Windows UI is surely broken.)

As you can see, I've added a memory viewer. If you use the memory map that I posted you might see what some of the stuff in the memory window means.

Attachments

generalnotes.txt (13652b) - views: 34
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 01-12-07 03:32 AM, in SM64 Coordinate Help Link
http://board.acmlm.org/archive/thread.php?id=12971

The vertex format is first described on page 3 and then more precisely a few pages later.
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 01-15-07 09:35 PM, in A couple questions on Mario 64 modding. Link
The answer to both of those questions can be found in the archive thread, VL-Tone's document, or one of the SM64 hacking threads here.
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 01-17-07 05:10 AM, in A couple questions on Mario 64 modding. Link
A description of the MIO0 compression format, along with links to a compression/decompression tool, is on the first page of that thread. The MIO0 data is pointed to by the 0x18 level script commands(see VL-Tone's doc).
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 01-20-07 05:24 AM, in Current projects Link
Super Mario 64 stuff. Picture attached for those who like pictures.

Note that because a 0x0e geometry layout command was replaced, all of Mario's different kind of heads are being drawn on top of each other.

Attachments

Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 01-20-07 10:44 AM, in 74LS139 vs MAD-1.... encoded? Link
I took a quick look at the pinouts for the MAD-1 and 74LS139. It looks like they work very differently. Therefore, I'd not expect FF4 to work on a MAD-1 cart.

You will need to get a hold of a 74LS139 cart or rewire a cart to use a 74LS139. For that, you will need a schematic of a FF4 cart and quite a bit of work. Just swapping the chips will not work. If you try that, you might even let the magic smoke out.
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 01-25-07 09:46 PM, in A couple questions on Mario 64 modding. Link
Originally posted by mortalkenshi2
How did you find that thread anyway since it was from an old acmlms board...


Probably because I posted a link to it in the other recently created SM64 hacking thread.

BTW anyone interested in ASM hacking SM64 might want to get:
http://www.dextrose.com/files/n64/sources_n64/mario-resource-by-nagra.zip
I can't beleve I didn't know it existed until less than a month ago. It even predates Acmlm's Board!
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 01-26-07 12:04 PM, in Super Mario 64 Hacking discussion thread - READ THE FIRST POST BEFORE POSTING! Link
I found out what the second byte of the geometry layout commands is for. If the command has a GBI pointer as an argument, the second byte specifies which of the game's preset render modes should be in effect when calling the display list.

During rendering, the game makes a pass over the internal structures that are created from the geometry layout commands. The game collects all display list pointers needed for the current frame into a number of groups. The group that the pointer goes in is determined by the second byte of the geometry layout command. Then, after going through internal geometry layouts for objects that are being drawn, the game goes through the groups. For each group, the game sets the render mode for that group, and then calls the contained display lists.

The reason the display lists are grouped by render mode is so that translucent polygons can be drawn last, possibly among other reasons. If translucent polygons are not drawn last, the rendered scene would not look right.

BTW, this looks like VL-Tone's last mention of the editor:
http://www.ipodwizard.net/showthread.php?t=15544&page=3#post170403
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 02-02-07 04:15 AM, in A bit of help with THUMB and jumps? Link
I don't have any experience with ARM, but I can suggest a couple of general strategies that might help. First, most CPU architectures support an instruction that jumps to an address in a register. You load the target address into a register, then jump to it. Another option some architectures support is pushing an address onto the stack and executing a return instruction.

Like I said, I have no experience with ARM, but I have yet to see a CPU architecture that doesn't support at least one of the techniques described above.
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 02-08-07 05:34 AM, in Lunar Compress issues Link
It looks like part of the problem is that the functions in the DLL are C style and the main program is trying to call C++ style functions. To support function overloading, methods, and as a layer of error checking, C++ mangles the names of functions in the object file in a way that encodes the function's return and argument types. Therefore, the linker can't resolve the function symbols. If you are sure that you have directed your IDE to import functions from the DLL, try changing: 
#include "../DLLCode/LunarDLL.h"
into: 
extern "C" {
#include "../DLLCode/LunarDLL.h"
}
in smw_example.cpp. If your IDE isn't importing from the DLL, which could also cause this problem, then I can't help much.

It also looks like Smallhacker's IDE is trying to build the program as a console app based on the fact that the linker is looking for a "main" function. I haven't programmed for Windows in a long time, so I'm not equipped to explain how to fix that.
Cellar Dweller +

Red Koopa









Since: 11-18-05
From: Arkansas

Last post: 6322 days
Last view: 6313 days
Posted on 02-09-07 07:53 AM, in Lunar Compress issues Link
I got it to work on my brother's Windows machine. For some wierd reason, FuSoYa didn't provide an import library like a DLL author normally would. You can add LunarDLL.cpp to the project and it will load and call the DLL.
Pages: 1 2 3 4 5 6 7
Acmlm's Board - I3 Archive - - Posts by Cellar Dweller +


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.051 seconds; used 416.06 kB (max 520.61 kB)