Home | Forums | What's new | Resources | |
Elbesem Engine |
Zaksund - May 31, 2005 |
RockinB | May 31, 2005 | ||||
Holy cow! Thanks for your work! Rather than docs you would need code examples. It'll be included in SaturnOrbit. BTW: what is sound animation? How good is E2_lib.h tested? Good idea to have a .h file instead a library .a. As far as I know, GCC can't perform optimizations across source files, so best option is to have it all in one .C file. BTW: Anyone else hoping that the LLVM... compiler approach gets a SuperH packend? This would give performance...
The Linescroll function is the key to performance for all apps that have to transfer images from work RAM to VDP2 RAM. A bitmap scroll plane got fixed dimensions, thus placing an image of other dimensions there must be done linewise - or using the linescroll and send all at once via DMA. Sample apps to take profit: my emus, my voxel renderer. The problem is to compute the linescroll table. CWX implemented a linescroll example, but it's fixed to certain parameters, he took the table from the docs. |
Omni | Jun 1, 2005 | |||
The "linescroll" is simply a DMA transfer of pixel data from work RAM to VDP2 RAM? Is that right? |
Zaksund | Jun 1, 2005 | |||
Oh man, I didn't even know that linescrolls were that technical. They are normally used to give scrollplanes a sway effect right? Like to represent heat lines or rippling water...the only example of what I'm thinking that comes to mind is how the clouds in the second stage of Cotton Boomerang shift up and down as they scroll by. I hope that's them. But hey, I was thinking about removing all WIP code and stupid extras from the library. You know, stuff like...camera clipping, light source clipping, and the biggie...relative motion. Gah! I just can't figure relative motion out!! I was using 'slCalcPoint()', but while that works great for rotation on the Y axis, it doesn't work properly on the X & Z. So pretty much what we'll have left after all my experimental crap is gone, is a nice and stable release. Sure you won't be able to make any racing or flight-sim games, but at least what you will have, will work properly. What do you think? Anyone think of anything that should be added, removed...whatever, go on and post it. Oh yeah, and if you can code anything in there better than I can (As you can see, my code is incredibly BASIC) go right ahead!! :lol: "Silence the dischord!" Kudos to anyone who knows the excellent PC game that's from See ya'!! |
Omni | Jun 1, 2005 | |||
Light source clipping? Never heard of that... Um, okay. So...if I send a 320x240 image to the 512x512 scroll straight through DMA...it would indeed be distorted, and actually appear at an angle, since every scanline would be off by ... (something 512 minus 320), right? So, linescrolling...um...fixes this, and puts each ...line of the image... on the proper line of the scroll? That seems kinda sensible. Though I also thought that linescrolling did have something to do with scanline-based effects like waves and stuff. Maybe it does both? Does that sound remotely right? |
mrkotfw | Jun 4, 2005 | |||
now this is great! i was going to write my own lib, but gba has taken most of my time; what i really want to now is how on earth did you understand the vdp2 doc? i just checked the two header files out. i see that you've included all your functions inside a header file! :looney i thought you completely wrote an entire sgl-like library from scratch but anyways, great job on the code -- it just needs ... organization :cheers |
vreuzon | Jun 5, 2005 | |||
good work ! Added after looking at the code : 1. I wonder after piratero why you put code in a header file. 2. About peripheral, maybe you could add some sort of multitap support (not only 0 and 15) ? |
Zaksund | Jun 6, 2005 | |||||||||||||
GAH!!! I did some maaaaaaajor bug checking yesterday and found quite a few things that I gotta take care of for the stable release. For example: I was using 'TEXTBL & PICTBL' instead of 'TEXDEF & PICDEF' for 2D image rendering...but for some reason this causes the images to be drawn in half
:lol: Hah, I can totally see where you guys are coming from. It just started as a few routines to keep my main source-code smaller and more organized, but it just kept growing!! Before I knew it, there was about 12,000 lines in there!
Funny you should mention that! I was thinking about supporting the multitap and the saturn mouse, but I don't physically have either of them, so I wouldn't feel comfortable coding for them if I couldn't be sure they worked. But hey! If anyone wants to write routines for them, I'm not gonna say no to code!
14 months of trial and error :lol:.
*sigh*, I wish...that would be a dream. But, I can honestly say without a doubt that something like that is waaaay beyond me! But yeah, I'll leave the previous release up there for download till the stable one is done, that way folks can experiment...and get used to the way it works. Oh yeah!, thanks for the feedback guys, are any of you thinking about entering the coding contest? - See ya!! |
vreuzon | Jun 7, 2005 | |||
zaksund : Il'd like to use your libs for my contest entry, but i can't find your example anymore, and the lib itself is not very self-explaining. Could you give an example code ? If I use your lib, I'll patch something for multitap support. |
Zaksund | Jun 8, 2005 | |||||||||||||||||||||||||||||||||||||||||||
Sounds like a deal! :lol: Here's some sample source for how to use 2D 32K color sprites. However, since you've still got the buggy libraries...your 2D images would be drawn in half with some distortion in the upper-left hand corner. Don't sweat it though! This problem has already been fixed! I've been working like mad to get any bugs resolved and this was the first one I took care of. On Monday, I'll put the new stable library files up for download along with some examples that are sure to make things easier. But till then, here's an example of how sprites work.
Code:
Below is an explanation of that source, but its pretty long!! Alright! Now this example assumes that there are 9 2D images in the file 'sonic_00.txt' hence:
Code:
_____ In the line
Code:
_____
Code:
_____
Code:
e2_IMAGE2D_32K_load_from_CDROM(18, "sonic_00.txt"); and for the next file, you'd say: e2_IMAGE2D_32K_load_from_CDROM(27, "yourfile.txt"); Because 18old images + 9new images = 27. So 27 is our new starting slot for the next set of images. Hope that make sense. _____
Code:
_____
Code:
_____
Code:
_____
Code:
Just like how:
Code:
And so on & so on...until our last frame. _____ Hey!! Wake up!! We're almost done here! :lol: Next we create a 32K EXTRA type sprite to be animated (extra & advanced types...heh, anyone else here play KOF?).
Code:
_____ Now we've gotta set the properties for the sprite:
Code:
This translates to: "Take 32k extra sprite #0, YES...show it onscreen, Position it at (0, 0, 200) onscreen, Rotate it 0 degrees (don't rotate it), Scale it by 1 (don't scale it), Don't shrink or make it larger according to its Z position, YES...if the X position of the sprite is less than -160 or larger than 160, or if the Y position of the sprite is less than -120 or larger than 120, or if the Z position of the sprite is less than 100 or larger than 400...then don't even draw it onscreen, And don't flip or mirror the sprite...just draw it as is." _____
Code:
_____ And finally...
Code:
This translates to: "Animate 32K extra sprite #0." _____ Hey, that's it!! Hopefully after reading through this...the comments at the start of these routines will make alot more sense now. Heh, if not...just hold out till Monday or post your question!! Good luck! See ya'!! |
Zaksund | Jun 9, 2005 | ||||
Hmmm, I know I've mentioned this before buuuuut, here's what the source to the example above would look like if we had used the tools to create the animation and the sprite and loaded them from CD instead of making them in-code.
Code:
And that's it! I'd say that's a pretty cool deal for only like an extra second of loading. Okay, stick a fork in me....you guys must be like :blah. Later!! |
RockinB | Jun 10, 2005 | |||
Hi Zaksund! After working for so long on E2, wouldn't you like to use it by yourself to make a small game? An entry for the contest, maybe? :agree |
Zaksund | Jun 12, 2005 | ||||
Just as promised guys Here's the new Elbesem Engine - Stable Release (version 1A) [attachmentid=1336] And here are some coding examples...more to come!! [attachmentid=1337] I've tested all of them, and they work properly. The examples are pretty basic...this set focusing on input devices, bitmaps, fade transitions, and 2D sprites. My favorite examples would be: e2_ex01 & e2_ex08.
Sure thing, count me in!! But I'm still trying to decide between an on-rail shooter, or a small Alone in the Dark 1 style game (just a few scenes). But I'll pick one soon enough. Like always, any feedback is appreciated!! See ya'!! |
vreuzon | Jun 14, 2005 | |||
I tried to segment your lib in order to use the pcm and cd parts only (sgl paletted sprites are ok now for me and I don't need the animation part). I'll do this work for the full lib if it's valuable to somebody. First compilation was full of warning, mainly due to "defauts to int" for functions. I Didn't succeed in executing the binary for now. Can you tell me the limitations of pcm sound in term of channels and speed ? |
RockinB | Jun 14, 2005 | |||
Hey Zaksund, I tried some of your example code on my Saturn, it's fine stuff, it is. Those marching sonics are my favorite , sonic forever! For the future you should try to do more computational stuff on PC instead of Saturn. I'm speaking of the TXT files, you should think about using binary files instead, maybe with optional compression. Now it takes some time to start up and I believe with TXT files you can easily reach memory borders that are not neccessary. In my WinterSports Eins game for Saturn I used the almighty tool BGCON to compress backgrounds and sprite animations(although the tool is not meant to be for sprites). The animations were to huge to fit into the VRAM, so I had to implement animation via exchanging the sprite image in VRAM with one of those stored in low work RAM. Nevertheless I had to use animations stored entirely in VRAM, too. Keep up the good work! |
Zaksund | Jun 22, 2005 | |||||||||||||
Oops...was gone for a few days, sorry. Well, that & I picked up Dragon Force again (we all know how this game eats DAYS of your life).
I know what you mean. I think I can only hold like 50 64x64 sprites in the VRAM at a time without corruption. You're right, to use any more you'd need some type of image shuffle routine like
Code:
Ah, I was wondering how long I could get away with this :lol:. You saw how long it took to load a bitmap huh?....like 5 seconds!! Imagine how tedious RE2 would've been if it took 5 seconds to load a bitmap everytime you changed scenes (frustration at AITD2 on the Saturn comes to mind...though I still love infogrames for the PC incarnations of the series...heh). Guess its time for me to study up on binary file manipulation...Or better yet! if you've got a simple example that'd be ace!!
Uhhhh, Rockin'-B can probably answer this alot better than I can :lol:. I just know the basics...8 channels total(0 - 7), stereo takes 2, mono takes 1, and that stereo effects are freakin' huuuuge!(I use mono whenever possible) Sorry I can't be of more help. As far as library work goes, I just rewrote a few things like making paletted images just as easy to use as 32k images. And changed the way controller input is handled. Made Fades a helluva lot easier to use. And I started optimizing data types...found out I was using ints in alot of places where a simple char would do, stuff like that. Well, thanks for the feedback, and keep coding guys!! See ya! |