WIP - Castlevania Demo!

Use this forum to share and discuss Uzebox games and demos.
User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Castlevania Demo!

Post by uze6666 » Mon Sep 10, 2012 2:58 am

Cool, I'll get that figured out as soon as I can.
No hurry, I'm also pretty busy on other stuff right now. More I think of it, more it make sense to use an already existing, dedicated CV level tool. I'll dig you code shortly and refactor my code to use the new map format.
It would be very neat to have multiple members working in parallel. Probably difficult to do and organize right now, until data formats are totally decided, but at some point maybe you could put out a "To Do" list so people can start moving. I'm sure some artists would be very useful for graphics refactoring for a new look and lowering ram tile requirements for sprites.
Yeah, can't agree more. Though, getting started in not the real challenge, it's more having it going and finished...we have many programmers, what we need a good project manager. Yep, sometime, they *are* useful! :lol:

User avatar
schepers_cp
Posts: 125
Joined: Tue Feb 04, 2014 9:48 pm
Location: netherlands
Contact:

Re: WIP - Castlevania Demo!

Post by schepers_cp » Sat Oct 11, 2014 2:25 pm

i know this is a huge sort of bump, but is there any more progress on castlevania? :)

User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: WIP - Castlevania Demo!

Post by uze6666 » Sat Oct 25, 2014 2:25 am

Two years already! What a shame... :oops: Unfortunately no progress, I stopped when I realized I would not have enough ramtiles for a decent amount of sprites. Simon Belmont and his whip already takes most and that didn't leave enough for the enemies. I was supposed to work into some better sprites rotation/flicker approach. Lee, did you have something on that?

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: WIP - Castlevania Demo!

Post by D3thAdd3r » Sun Oct 26, 2014 6:53 am

Yeah this is very tough to do right now. Essentially you have to break ground at every step to handle the stuff no one has ever done yet, which is really all the hurdles that has kept anyone from making a full and complex scrolling game. The sprite requirements here are higher than a Mario type game too..my main thought on that is "...'dat whip!? :shock: "
I believe this can be done and turn out amazing, and I also believe the engine that does so immediately makes a plethora of scrolling games possible. Mario for instance, would probably not be as tight of a squeeze on resources. Partitioned sprites are really a must for any of this I'd say. It's a modest 10-15%+ gain, but we are taking about stuff on the extreme edge of possible at this point; right where most of us enjoy it!

So I did think up a new theory on what the best sprite rotation system would be. Of course it ends up being semi-complicated and cpu intensive but I think it will help considerably. The main concept is that some sprites are more important than others and additionally that some parts of those sprites are more important. Basically each 8x8 sprite can take up to 4 ram tiles, but often times there is just a couple pixels or none actually drawn on the ram tiles where the sprite simply went over the 8pixel boundaries but that part of the sprite is blank. The concept could work a couple different ways, 1 requiring significant overdraw on ram tiles(that is blitting higher priority stuff on top of stuff we had already used that ram tile for), and the other being a multi-pass approach on blitting in ProcessSprites().

The first approach I question whether we would have the cycles available, but basically BlitSprite() returns how many non-clear pixels were drawn on the ram tile just drawn and we keep track of that number(to save stack/ram space, put it in ram_tiles_restore since we will have already restored everything at that point?). When we run out of ram tiles but are still in ProcessSprites trying to draw stuff, we draw it to a reserved ram tile and calculate how many non-clear pixels where drawn. We scan through the list again looking for ram tiles where less pixels where drawn, and if found we simply copy from that reserved over that ram tile. Then at the very least we have maximized the number of actual sprite pixels drawn, and don't have a bunch of mostly empty ram tiles which happens constantly in these games currently. Somewhere at the end we make sure to use that reserve ram tile too :) Might be a more clever way to handle the details but I haven't had time to explore it.

The second approach is a different modification to ProcessSprites(). Where normally we try to handle drawing up to 4 ram tiles for each sprite, we instead will only draw 1 of them on the first pass. We will end up making 4 passes through all the sprites this way. For each sprite in the sprite tile table, store 4 numbers. These number indicate which parts of the sprite are more important. We calculate this imagining that the sprite is evenly crossing 4 ram tiles, this works because we just look and say oh this is the back of simons boot. The least important part is the very back/bottom and it will be commonly drawing just a few pixels. Simon's head of course would have maximum priority for every quadrant because it would be very obvious when that flickers. In cases where only the x axis was off alignment we would add the upper left and lower left together and draw it the first pass, the second pass will fail because there is no lower left quadrant if it's aligned on y. Likewise for the right side to calculate its priority. The reason for that is that a sprite that is aligned on at least 1 axis is much more certain to not be wasting ram tiles on just a couple pixels. Of course the same way for the y axis and yes I know this sounds like a headache in the form of a rather late night poorly edited explanation. I think just a mental experiment by anyone, which is all I have done yet, shows that it will have a noticeable effect though.

A third possibility would be to combine those methods if cycles permit. Partitioning + Advanced Sprite Rotation, I feel comfortable in saying we could have 25-35% more perceived sprite pixels on screen that we are used to seeing given the same amount of ram tiles. I did a write up on some of my thoughts on the subject and went a little overboard. It's in my wiki rants. The actual sprite rotation I don't have the details hammered out on, but I will write it up and test it out when I get a few backlogged Uzebox tasks done. I think with a couple guys teaming up we could really advance scrolling on Uzebox. I volunteer for the work on the sprite rotation, another big issue is can we scroll from the SD card?

User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: WIP - Castlevania Demo!

Post by uze6666 » Sat Nov 01, 2014 2:39 am

I have a lot of catchup up do to on the wiki to fully understand you last post! :oops: I'll read all your articles on partitioned sprites and come back!

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: WIP - Castlevania Demo!

Post by D3thAdd3r » Sun Jul 09, 2017 2:16 am


Maybe not that related to the Uzebox remake, but I found this and it seems pretty awesome! Usually I do not like 2D->3D remakes very much, but this one is really cool if for nothing else than how much lighting adds to a game like this. If not that, then that whip effect...damn satisfying sound!

User avatar
L4rry
Posts: 239
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: WIP - Castlevania Demo!

Post by L4rry » Mon Apr 08, 2019 6:59 pm

How did I miss this game growing up!?

Got myself a nes mini over the weekend and started playing. Three levels in and I'm hooked.

Looking forward to seeing this materialize on the uzebox someday.

User avatar
nicksen782
Posts: 667
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: WIP - Castlevania Demo!

Post by nicksen782 » Mon Apr 08, 2019 11:56 pm

It is rather impressive! He even put the screen transition when opening the big doors. And to think, this demo was done in 2012.

I think an issue that is holding some games from the Uzebox is how MapSprite2 and MoveSprite work. When you do a MapSprite2 you have to specify what sprite number you start at. Then, for instance, if your spritemap has a 2x2 tile map then 4 sprite numbers would be taken (and in order.)

All sprites must be contiguous. These two functions are just helper functions. As said before, by Uze, (likely while thinking about this game and the whip) that you will need to create a more specific helper function in some cases. I'm working on another game right now that could use something like this where a tilemap (dynamically created, using vram tile ids) would do what MapSprite2 does but based on the vram id it will detect if the source is a ram tile or not and then set that flag accordingly. In my case, I would make the tilemap array by copying parts of vram. vram ids less that RAM_TILES_COUNT are ram tiles (it can be slightly confusing but if you remember that rule then you are good.) Any vram id >= RAM_TILES_COUNT is a flash tile.

Also, sprites CAN be sourced from RAM. (SPRITE_RAM flag set on the sprite, SPRITE_RAM_ENABLE set in the Makefile). I have actually tested this and it works just fine but it is expensive ram-wise. All tiles in the sprite map would need to come from the same source with MapSprite2. However, it does not appear that the kernel actually requires this when drawing. It just looks at the sprites array, checks the flag and reads from where that tile indicates the source is.

If sprite numbers could be non-contiguous then we could re-use sprites out of order (wherever there is a free spot.) Again, I don't think the kernel really "cares" if a sprite is part of a sprite map. It just draws what is in the sprites array.

So, I'm doing that for a game I'm working on and it is very likely that a similar technique would need to be done with Castlevania. Especially if you want enemies.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest