On a side note, before anyone says, “That’s not a game!” this is not my “real” project. This is a little something I started working on last weekend. At first it was just a demo that had a crippling bug. After fixing the bug, I decided to develop it into a full blown app. Disappointingly, I know I’m not going to be able to finish my main project, but I want to enter at least one thing in the compo that’s complete. This is my first foray into procedural graphics, and I used a different method than drawing to the frame buffers. Thus, the project source includes a nice little header file I made to do screen rendering using my method. All the information you should need is in the readme. Hope you like it!
(Let me know if you find any horrible bugs. ;-))
To be honest I dont even know what this does but then again I am no VB game maker
Nice work, Fwirt! You totally surprised me with the unexpected Sierpinski triangle(/gasket/sieve) on the warning screen! π
I’m really going to have fun exploring the BGMap drawing code! :thumpup:
Suggestions for improvement:
1. Some kind of instruction screen (although the readme is sufficient, I just tend not to read them before diving in :-P)
2. Allow one to abort rendering.
Hmm… I guess I could have select bring up the instruction screen instead of hiding the cursor… But the problem with aborting a render would be that because of the way I have it drawing right now, if you stopped in the middle of the render, you would be halfway between two images. I guess I could keep track of the previous coordinates and just redraw the old screen at that point, but then you’d have to deal with the time that took, so it’s just a messy situation. I’d double buffer if I could, but there’s not enough char memory to double buffer a full screen with the BGMap direct draw method I’m showing off. (I talk about that problem in the readme.)
I’m glad you liked the Sierpinski, I had hoped that would be a nice surprise. π
Firstly, I think this is a great idea! I’ve always been a fan of Mandelbrot’s myself, so I like it!
So I just tried this on a FlashBoy Plus, and it is rather buggy. There are vertical lines, and the graphics “shake” left and right. But regardless, I really like the concept!
wazzal wrote:
So I just tried this on a FlashBoy Plus, and it is rather buggy. There are vertical lines, and the graphics “shake” left and right. But regardless, I really like the concept!
Oooh, really? Sorry about that… It works flawlessly in mednafen. I wonder what’s causing the vertical lines… Where do they appear? Does the screen shake only when rendering or the whole time?
*ahem*
Also, I have the feeling that people aren’t reading README.TXT and consequently aren’t figuring out the controls… This is a note to people who skip the readme: The most important control for this app is holding A and dragging a box around someplace on the edge of that weird shape. The whole point of the Mandelbrot set is that you can zoom in forever. It’s kind of disappointing to me that the screenshot that KR155E chose for the front page only shows a zoom out… If you’ve never heard of the Mandelbrot set, here’s a Wikipedia page, and here are a ton of examples of the cool things you can see if you spend some time with a program like this one. Following this post are some screenshots of what you can see if you play around with the compo entry… (Note that I pressed Select to disable the cursor. I left the overlay on so you could see where I was, but you can also disable that by pressing L. Do I really have to tell you to go over the readme at this point? π )
Attachments:
Oh! So that’s how you zoom in. Sorry, I have to admit that I was in a hurry and skipped the readme… Will replace that screenshot!
Hey, thanks KR155E! I was kind of worried that people were going to think my entry was really boring…
Fwirt wrote:
Hey, thanks KR155E! I was kind of worried that people were going to think my entry was really boring…
Oh, yeah… it’s a thrill-a-minute! π
heh, only kidding! It’s very impressive and makes a great addition both to the VB’s library and to the pool of homebrew code. I hope you win, and I’m not just saying that.
I have to admit that I, too, had to look at the readme… probably because the last Mandelbrot explorer software I used ran in MS-DOS (on my 486), used 16-color VGA mode, and was made before the VB was even a twinkle in Mr. Yokoi’s eye π
I’ve got a question about your code, though: obviously, it’s the fractal calculation code that makes it slower than real-time, but have you done any benchmarking (or algorithm analysis) on the BGMap-as-framebuffer code itself?
RunnerPack wrote:
Oh, yeah… it’s a thrill-a-minute! π
Well when you zoom really deep, it might take it that long to render… π
I haven’t done any benchmarking, but the drawing code should be pretty efficient. The setup function is O(n) and the draw function is O(1). You could make the setup function faster if you commented out the part that clears all the chars, but the setup function is only run once at the beginning of your program, so that’s probably not an issue. The real time-hog is just the Mandelbrot routine, as it has to do a whole bunch of FLOPs per pixel rendered. At one point I was toying with fixed-point math, but it didn’t seem any faster.
But now that I think of it… the BGMap method probably is a lot slower than the framebuffer method in practical application (polygons, etc.), as you have to clear the screen manually.
BTW, giving credit where credit is due, this idea actually came from the official development manual:
Virtual Boy Development Manual, P. 2-6-1:
Another method to include polygons is to place characters in a row in the BG map or place OBJs in a row on display, and write the polygon characters in character RAM. When this method is used, display priorities can be readily assigned to the polygon characters and normal OBJ and BG characters.
Isn’t that the way Lameboy used to do his drawing? I remember him making a raycaster which was ridiculously slow, and I think he used BGMaps, rather than drawing directly to the framebuffers. I don’t think the BGMaps were the reason it was slow though π .
DogP
Aha, I figured someone else had probably beat me to it. Well, at least it’s library-ized now.
Funny story, I just wrote my first raycaster in Java a few weeks ago and was wondering how slow it would be on VB… π
Fwirt wrote:
wazzal wrote:
So I just tried this on a FlashBoy Plus, and it is rather buggy. There are vertical lines, and the graphics “shake” left and right. But regardless, I really like the concept!Oooh, really? Sorry about that… It works flawlessly in mednafen. I wonder what’s causing the vertical lines… Where do they appear? Does the screen shake only when rendering or the whole time?
I flashed it on just now to double check, and the vertical lines appear from start up. They are essentially black lines spread out amongst the whole screen.
The horizontal shaking occurs the entire time as well.
It really is quite intriguing as to what is causing these issues on the real system vs mednafen
Hmm… Looking back at my source code, I realize that I forgot to call vbSetColTable(), could that be causing it? I’ve always forgotten to call that because it’s never affected how my code ran in an emulator, but I wonder if that would cause vertical lines and shaking on real hardware. As a double check, I just ran it on Reality Boy and it runs perfectly there too… I would attach a version with that function call in, but I don’t think it would be fair to do that until after the voting deadline has passed. But wazzal, if you have the toolchain built, feel free to add that line to mandelbrot.c right after vbDisplayOn() and let me know if that fixes it.
Fwirt wrote:
Hmm… Looking back at my source code, I realize that I forgot to call vbSetColTable(), could that be causing it?
First, you should check to see if your crt0 is already setting up the column table itself. If it is, there’s no need to insert a call to that function, and the problem is likely elsewhere (although it does sound suspiciously like a CT problem).
Hmm… I just looked at the version of crt0.s that I built from, and there’s a line commented out…
/* Column Table */ /*jal _setcoltable*/
I’ll uncomment that and rebuild it.
Ah thats why i couldn’t use it over the weekend, if others also feel its ok to release the modded code I would love to see it so i can play in my VB and vote accordingly, my voting is based on using the entries on a Flashboy in the hardware.
I like the concept, Ive not playing with a fractal generator for many years, I have had a look at all the entries on an emulator but i wanted to reserve my true views on all of them for the hardware experience.
The bugginess did give me mild panic that my VB unit had suddenly got glitchy, i had to dig out an official cart to check, and hence ended up spending a good hour on Sunday playing Mario Clash again.
It would be nice if I could release a fixed version, since this bug didn’t appear until it was tested on real hardware after the contest was over. (If I could have tested it on real hardware I would have… Maybe I’ll be able to afford a FlashBoy one of these days.) I don’t believe there was anything in the rules about posting an update after the deadline, but I’d want to be sure that I wasn’t going to be stepping on anyone’s toes before I did it. I promise I won’t add any new features. π
I hope I haven’t lost too many votes because of this… >:(
Sure, post the update!
But, since it comes in after the deadline, I am afraid I can’t include that in the ZIP file which can be found in the news post and which should be the base for user votes. :/
Great! I don’t care that it’s not in the zip file. Here’s the updated version, my crt0 should be fixed, but my main also calls vbSetColTable() just in case. As an added bonus, I actually set the header info this time. The publisher ID “SP” is now taken. π (I’ll update the dev wiki.)
Someone should try running it on hardware and let me know if that resolves the issue.
Attachments:
^I just tried running it through my FlashBoy and it works!
Renders without any error π