Language…
14 users online: CalHal, deported, fabricio09532, feb31st,  Fernap, Golden Yoshi, Green, Heitor Porfirio, jadenmk, matt112986, Metal-Yoshi94, Pink Gold Peach, sholmes, signature_steve - Guests: 190 - Bots: 115
Users: 64,437 (2,485 active)
Latest user: Cesarbr

Posts by OwenCraft

OwenCraft's Profile → Posts

  • Pages:
  • 1
Say there would be a bridge of that block, and you wouldn't be able to cross it unless you have all the 7 Yoshi Eggs, then the bridge will be passable.

I would also like another block that would turn from Solid, to Dotted after the same action (vice versa from the other block).
Track Name
Mario World March #3

Sampled?
Use custom samples definitely.

Audio Reference
https://www.newgrounds.com/audio/listen/13003

Note Data Reference
It's pretty much a remix of the Super Mario World overworld theme, they have somewhat similar notes to the original.
Name:
A modification of Blind Devil's cursor sprite to include vertical scrolling

Type:
Sprite

Description:
I want a modified version of Blind Devil's cursor sprite to where I can scroll the screen vertically up and down. The default buttons for scrolling should be L and R.
I mean the theme is cool and all, but my eyes are being blasted right now.
Thank you so much! I feel tempted to port everything to a new ROM in my hack right now.

Another thing, both v1.2 and 1.3 of this patch with SA-1 just doesn't work at all on Snes9x v1.59 and above. I found a way to circumvent a game crash in v1.2 (you can view the v1.2 page to see how), but not with the $F1 command. If you have the same problem as me, you should use an emulator like BSNES or BizHawk for the time being.

Also, I mentioned this:
Originally posted by Owencraft
...for every level you intend to use in your hack, enable advanced bypass settings for layer 3, then set the Y and X offset to 12 and 10 respectively.

I forgot to mention I was using the nuke status bar patch, so you should only do this when using that patch.
About 8 months ago, I was bored, so I coded a simple 3D game engine in MS-DOS in C. It took quite a lot of work.




The game engine uses VGA Mode-X with a 320x240 pixel resolution. The player immediately starts at the origin point of the map: (0, 0, 0), and can move with the WASD keys and look around with the mouse. There's no physics here, so the player can phase through walls and fly.

There are placeholder images at the bottom of the screen showing the player's HP and Ammo, though I haven't implemented this feature in yet. There's also some debug text at the top showing the frames per second and other miscellaneous info, which can easily be changed in the source code.

Oh yeah, the code is heavily unoptimized, and I'm a bad programmer. The triangle-rendering code is especially unoptimized; you can see the FPS drops to the 8-16 range when I get close to the map.

There's still lots of things that I need to add to this project, though I doubt I will ever finish it because I'm really slow at working on shit. Some of my main goals for updating this engine are:
- Sound
- Physics
- Enemies, items, NPCs, etc.
- Saved Games (I feel I could do this easily)

And here's one final screenshot of Princess Peach to go along with this C3's theme:



Let me know what you think of this game engine!

UPDATE: My project is now on GitHub!
Originally posted by Heitor Porfirio
For this project, do you plan for it to have any story?

I was thinking of creating a first-person shooter that takes place in the Galilean moons, the four moons orbiting Jupiter, though I haven't thought of a definitive story yet.

I was inspired to make this project because of DOOM and also Half-Life. I actually bought both games last Christmas while working on this project.
Originally posted by patcdr
Have you tried running it on real hardware? I'd be willing to give it a test on my Windows98 machine sometime in the future.

Not yet. I tested this game in DOSBox with a simulated Pentium CPU at 100MHz, and with 8MB of RAM. The bin folder that holds all of the game's data, including the game itself, is currently 376 kilobytes in size. Judging by these requirements, I think your Windows 98 machine would run this engine just fine.

Originally posted by bebn legg
I can't imagine how much of a pain it must've been to put this together, in C of all languages, but the result looks really cool!

Yeah, it really was a pain. I had several moments where I was purely frustrated and quit the project for a few weeks or months, but I inevitably come back to see what I can add or fix.

Originally posted by RussianMan
The effort here is admirable, and it's made for the old DOS system? Was it made completely from scratch?

Yes, I made it from scratch. The very first thing I remember doing for the project was printing lines of text to the screen to display the player's coordinates, then a few days later, I followed a VGA tutorial to render the screen, then I took off from there.
I made a few quick updates to the engine:

It now detects if SoundBlaster is enabled on the DOS machine or not. Still haven't worked with actual sound or anything.
There's now gravity in the game. I'm also trying to work with line-triangle collision, but it doesn't seem to work, so instead I used a simple test to check if the player is below Y=0.

I also created a GitHub repository to share my engine.
Originally posted by RPG Hacker
The new default setting for !vwf_var_ram_sa1 is $40C000, which might conflict with other patches, but hopefully those conflicts should be easier to find.

It turns out this new address conflicts with the SA-1 Retry Patch, which is also $40C000. Fortunately, the non-SA-1 addresses are $702000 for VWF and $7FB400 for Retry, so they don't conflict there.
To compensate for this issue, what other address would you set !vwf_var_ram_sa1 to?
If you are planning to use the Retry and VWF patches in your SA-1 hack, look at retry_table.asm and find !max_custom_midway_num. Next, set !vwf_var_ram_sa1 in vwfconfig.cfg to $40C0CD + (4 * !max_custom_midway_num), and you should be good to go! If you want to change !max_custom_midway_num later on, you'll have to change !vwf_var_ram_sa1 too. You'll also need to change that value for every sprite and block using the VWF patch.

I have tried it, and so far, there seems to be no problems.
  • Pages:
  • 1