11 March 2016 - Forum Rules
Started by Fire-WSP, March 19, 2018, 10:19:14 PM
Quote from: DarkSamus993 on April 20, 2018, 12:01:06 AMQuick opinion poll: Should I remove the empty space between sprites? My code ignores it anyway, but I also realize without it editing becomes a tiny bit more involved. It's not like we're hurting on space at the moment, but it would optimize the code a little (not having to calculate the 'true' start address of the sprite). This is just something I thought of to save ROM space and a few CPU cycles.
Quote from: Fire-WSP on April 21, 2018, 04:18:57 PMAlso if I recall right, somebody mentioned, that there is quite some lag in the originl game in later levels.
Quote from: Fire-WSP on April 21, 2018, 04:18:57 PMAbout the 64x64 walls, well with the new information now, I think it would end up like Jurassic Park.In JP it was no problem because the action was different. I am not sure if we really should try it.There are a few other cool things to try like a few aditional faces in the HUD, More/different mission briefing screens.
Quote from: Fire-WSP on April 21, 2018, 04:18:57 PMAbout your proposed solution:1) you mean go back to the way it was original?That would mean we need a tool for decompress and recompress?
Quote from: Fire-WSP on April 21, 2018, 04:18:57 PM2)with uncompressed, would space the only "problem" with that or there are other side effects?I still think that rom size does not matter that much today. !6Mbit is no problem at all.I doubt we would hit 32 Mbit and even that would be no problem.
Quote from: Gemini on April 21, 2018, 04:28:32 PMThe thing with literal sprites is that rendering them takes way too long, while only dealing with effective pixel writes via tables is muuuuch faster.
Quote from: DarkSamus993 on April 21, 2018, 04:46:20 PMThe lag is very noticeable on later levels when there's a bunch of enemies on screen at once.Yeah, I'm not going to worry about walls right now and instead focus on adding the other features we want.Yep, working on one now unless Squall_FF8 beats me to it.Functionally it would be the same, it would just eat up more ROM space. But it would be pretty pointless as you would still need a tool to be able to change anything (because all the column data, ptrs, etc. would need updated as well).Yep, I can see why they did it that way now. Even if what I did was a waste of time, at least it was good learning experience.
Quote from: DarkSamus993 on April 21, 2018, 02:22:50 PMThere's two ways to go from here:1) go back to the way it was with compressed sprites, coordinates, column lengths, etc.2) same method as #1, but keeping sprites uncompressed
Quote from: Squall_FF8 on April 22, 2018, 09:08:41 AMIf I understand well, #2 mean keep sprites uncompressed, keep structures for compressing from #1 but instead of pointing to compressed data, point to uncompressed? Is that it?
Quote from: DarkSamus993 on April 22, 2018, 11:41:41 AMYep, keep all the pointers and column data but use uncompressed sprites. You would still have to update all the ptrs & column data when something needs changed, so it would just be a waste of space. I don't even know why I mentioned it.
Quote from: DarkSamus993 on April 22, 2018, 11:41:41 AMI got sprite decompression working, working on the compressor now.
Quote from: Fire-WSP on April 21, 2018, 05:16:54 PMI don't think it was a waste of time. It was worth a try and it created lots of new information.
Quote from: Squall_FF8 on April 22, 2018, 12:37:03 PMWoah you are fast I also have decompression working
Page created in 0.068 seconds with 20 queries.