mellott124 wrote:
I also have a 128Mbit PCB cart which can allow an additional 128Mbit for expansion space (no game currently uses this). It has a 8k x 8 nvSRAM. It will be updated sometime in the future for a 256k x 16 nvSRAM. This is intended for large Homebrew titles. This cart is also reprogrammable.
Sounds like I could fit allot of Snatcher on such a cart. Cool stuff.
There are actually a number of ways some someone without coding skills can contribute.
1. Art: Quaze already mentioned it. Personally, I love looking at fan-art. There isn’t much for homebrew games though. I also had this idea of including fan-art as an unlockbale into my next game.
2. Graphics: If you already have artistic skills, you could try to learn pixel-art. For me it’s a constant problem to find good assets to use in a game. I can draw them myself but I rather spent my time on other things.
3. Music: If you know how to make music, that’s an important skill as well. Most Midis convert pretty good to the VB. For myself it is next to impossible to compose music.
4. Testing: It’s very easy to overlook bugs if you are the one developing. I have a group of people I like to sent my roms for testing. It’s usually more about finding bugs then about giving Feedback. Also don’t share stuff with others.
5. Giving Feedback: When I publish demo, it’s always good to hear someones else opinion. It’s always important to know how to phrase things though. It is easy to ask for features and stuff but you should be aware that you are asking someone (who is already burned out) to possibly spent plenty of time on a project he already spent some 100 hours on.
6. Reviews: When I publish something I read/watch every discussion and every Review I can find. Same as before, just be nice.
7. Show your stuff: It’s always cool to see one of my games in a game room.
thunderstruck wrote:
so someone can help drawing depth maps and stuff.
Hi thunder, I would feel happy to contribute some 3D conversion to this project 🙂
That’s cool. But as I said, it will take some time until I get back to it. However, I do have another game I’m working on for which I could need someone how is able to draw some nice looking items.
thunderstruck wrote:
I’m wondering if other games have more unused code as well. Faceball might have multiplayer code hidden somewhere after all.
I spent several hours checking other games (including Faceball), but unfortunately I didn’t find any traces of unused multiplayer code.
thunderstruck wrote:
I played it with my wife for a bit. I noticed some balls getting lost right when they were over the net though. But maybe that was just my link cable or something.
Are you sure that the ball disappeard for no reason?
If there is a (serve) fault and the opponent returns the ball despite the fault, then the ball usually disappears somewhere around the net. Take a look at a serve fault here: https://youtu.be/mXbPchEiptM?t=56
Might have been just that. Never saw it happening before.
M.K. wrote:
So first I modified an emulator to to help me identify data and code sections. Then I spent a while playing the game to collect enough data and to identify unused code paths. Next, I wrote a disassembler that was able to disassemble the whole game by using the collected data.
That’s a cool approach. I’m wondering if other games have more unused code as well. Faceball might have multiplayer code hidden somewhere after all.
It is pretty crazy that you managed to reactivate the multiplayer code. I played it with my wife for a bit. I noticed some balls getting lost right when they were over the net though. But maybe that was just my link cable or something.
Wyndcrosser wrote:
Thunder, any update on this by chance? We could also play thru the English game and start screen grabbing and writing down dialogue.
W
I did start converting more of the game but did ran into several problems. I actually did not program my converter very clean so it is rather hard to understand what I did back then. I will have to rewrite most parts. Due to some health problems I wasn’t able to do much during the last 4-5 month. Right now I’m programming a 2-player game, which will hopefully not be as complex.
After that I will most likely go back to Snatcher. I will try to make the tools I’m using less bound to my development environment so someone can help drawing depth maps and stuff.
mellott124 wrote:
I just reviewed TicTacToe source last night and it has some basic examples. It looks fairly simple.
I’m planning on compiling all the info into one location that I need to develop another cable. Maybe this could all get transferred to the link cable wiki.
thunderstruck wrote:
Hey everyone,
I received my Link Cable yesterday and will most likely put some code together on the weekend. Would someone be willing to publish some code snippets so that I (and others) have an easier start?
I know there are some examples buried in the forum and demos but I thought I might as well ask. Maybe even Mr. Anon is willing to share his code.
Can you post those examples? Doesn’t need to be perfect.
So, the image converter is in a pretty solid state and works fine within vbde. I actually did the same for my Midi converter. Because the code was in a horrible state I rewrote most of it. I also added my music player to libgccvb so midi conversion and playing music is now rather easy as well. I will try to make a video to show what I’m talking about.
Next I will start making a smaller game to see how useful everything actually is.
Krisse and I debugged the problem. Seems like the crt0.o is no longer calling vbSetColTable(). I could fix the demos by simply calling the method from code before vbDisplayOn.
Attached are the newer libs that do to vbde\libs\libgccvb\compiler. They are essentially the same the vuengine is using.
The interrupt names change as well, so the interrupt.h has to look like this:
extern u32 keyVector;
extern u32 timVector;
extern u32 croVector;
extern u32 comVector;
extern u32 vpuVector;
OK, so there seems to be a problem with vbde. If I build the demos or any other project they look fine in the emulators but the graphics are all messed up on hardware. I remembered that I had the problem before and that I asked about it in my very first post: http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=16936#forumpost16936
I noticed that vbde uses multiple versions of crt0.s and vb.ld. An older version for libgccvb projects and a newer version for vuengine projects. Using the newer versions in libgccvb does not fix the problem. However, if I use the newer vb.ld in combination with the crt0.o that dasi posted in the link above everything looks fine.
As the default makefile does not copy object files from the source directory I had to change the makefile to be able to compile everything properly.
I have to day that this is rather disappointing. I started converting all of my projects so that I can run them with all the compiler improvements and stuff. Now I had to switch back to older files.
M.K. wrote:
@thunderstruck
Congratulations for being the first one who found Lucky! I think you deserve a prize. Send me a PM with your email address and I will send you something cool.
I just wanted to add that I got my price and that I would have never guessed that this is possible. Very cool, thanks allot.
I actually started developing a new game. To make things a bit easier I started extracting my image-converter code into its own library. Right now all of my projects use a custom version.
I then added a precompiler to vbde that converts all images in the directory “images” into bgmaps and charsets. I also extended libgccvb with a generic image loading code. The converted images come with a load function, so adding images to a game is now extremely easy.
I sill need to make a view tweaks but I will release a first version very soon. I’m also considering to make all of this open source.
