This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - JamesV
Pages: 1 ... 3 4 [5] 6 7 ... 19
61
« on: January 06, 2016, 11:39:06 pm »
I'm getting close to getting the game somewhat playable on the 84+CE, there are just a lot of little Z80 -> eZ80 things to patch up (eg. "ld h,0 \ ld l,a" needing to be updated to "ld hl,0 \ ld l,a" etc.) In terms of the new campaign, Episode III: Impact, it will be a little different to Episodes I & II. Instead of just being a linear 12 level campaign, it will have multiple routes available. The current plan is to have around 30 levels, with a single play through taking you through anywhere between 11-14 levels depending on the path you take (around 5-6 different paths available). The paths that take less levels will have a slightly higher difficulty curve than the paths that take more levels. This one won't be set on a space station either, it will be on a planet surface & multiple towers, ala Alien Breed: Tower Assault. I've also got at least one more enemy getting added in (the "security guard" enemy from the previous Alien Breed IV game of the early 2000's that I did), and I have ideas for another 2 possible enemies that I haven't implemented before that I think would be cool 
62
« on: January 04, 2016, 05:15:44 am »
I've been thinking of a way you could somehow attach color data per tile, each tile would still only support two tiles but you could do something similar to RLE where you'd have an extra buffer keeping track of the current palette. Something like:
; bit 7
exx
ld a,(hl) ;hl' points to palette array
exx
sla d \ adc a,aIt's a bit slower and you'd have to inc hl' at the end of each djnz iteration. You could possibly get around using the shadow registers if you pushed bc (you could maybe move the push bc before the ld bc,288 to the vbcx3Row label), opening up C to use instead of D for the gbuf byte to rotate, then you could use DE to hold the pointer to the palette array. The palette array just tells you the first palette value, eg. 0 corresponds to palette entries 0 and 1, 1 corresponds to 2 and 3, 2 corresponds to 4 and 5, etc. That'd look something like:
; bit 7
ld a,(de) ;de points to palette array
sla c \ adc a,aThe overhead would be a bit less than my first idea, i think. Each tile would still only have two colors, but the map would be a bit more colorful. You'd also have to fill out the palette array as you draw your tilemap, but that shouldn't take up too much time. Definitely wish i had a CE right about now 
EDIT: And if you come up with something that's too processor heavy, there's always shifting two pixels per frame which would still look really nice.
These are some interesting ideas, chickendude. Thanks for the suggestions! At this stage I'll simply focus on getting the game playable on the 84+CE for starters, but you're giving some great inspiration to strive for greater results with this in the longterm! 8bpp is faster, the issue is that the original routines are written for the BW calcs so all sprite routines are drawn to a graphbuffer that has a 1bpp layout. Writing to a gbuf on the CE just makes it easier to maintain the code between the two calcs, otherwise you'd have to have separate code for the tilemaps and basically anything that interacts with the map (sprites, bullets, etc.). So (i assume) James just uses the same routines to scroll the tilemap.
Correct, the 84+CE version uses all the same sprite drawing & scrolling routines - the only difference (at this stage) is copying the "gbuf" to the LCD, which on the 84+CE converts the 1bpp data to 8bpp and scales up 3x. The main reason for sticking with the 1bpp "gbuf" is to keep the speed of the scrolling/sprite & tile drawing routines as fast as possible. I haven't done much work on this for the past week as I've been enjoying a summer week off work, but current status is that after many hours of work, the source now cross-compiles for both the 83+/84+ app version and the 84+CE program version. Now I just need to start stepping through the 84+CE version and get the game to a playable state.
63
« on: December 30, 2015, 01:49:37 am »
64
« on: December 25, 2015, 06:29:29 pm »
With some assistance from MateoConLechuga, the 3x scaling/drawing routine is now running substantially faster on the TI-84+CE. Thanks Mateo!
65
« on: December 23, 2015, 07:42:55 am »
Today I've finished off (for the time being) the new level event scripting that will feature in Episode III: Impact (and Episodes I & II will be patched to the new format as well). The new format gives me more power to add multiple triggers & events during a level. In the below screenshot there are a few examples: 1. After a certain amount of time passes, an in-level text block is displayed, and the darkness filter is enabled. 2. When the player walks up to the computer, another text is displayed and the darkness filter is disabled. 3. Bosses are no longer triggered by a single tile - an area is set (can be any rectangular shape up to 32x32 tiles in size) that triggers a boss (technically there could be multiple bosses in a level now), and in this case also modifies two tiles in the level to seal off the room (previously this was locked to modify one tile when a boss fight started, and one more tile when a boss fight finished). 4. When the boss is killed, multiple tiles are modified to open various paths out of the room, the countdown sequence is triggered, and the level is flagged as being ready for completion. Triggers & commands can be used in various combinations to create various events so that I can add more depth to the new levels.  Now that this is done, I'm going to attempt to start adapting the code and applying the new LCD routines to make it compatible with the TI-84+CE
66
« on: December 21, 2015, 05:08:26 pm »
Great work as always! Can't wait to see what comes out of this? Are you planning to release a tutorial/the source for your mono-to-color method at some point?
Certainly the code and details and implementation will be released - it's actually quite simple. The tiles/sprites are just drawn to a 768 byte buffer as they would be on the non-colour calcs, then it's just a special routine to scale this up either x2 or x3 as it simultaneously writes it to LCD memory. Do you use parctial redraw? Because different screen sizes run at different speeds, it seems to me you are not
Anyhow, this is cool
This reminds me i need to start working on my mincraft port to the CE
Partial redraw? I'm only writing as much data to the LCD as required each frame, which is either 3072 bytes (192*128/8) for the x2 zoom or 6912 bytes (288*192/8) for the x3 zoom (remembering that the LCD is in 1bpp mode to resemble the non-colour calcs). Or does the 84+CE have some kind of interlacing method like the CSE that I've missed in the documentation? Hey James, this is pretty awesome. Honestly, it doesn't look too bad at 3x resolution speed wise. I wonder what the bottle neck is though since the processor is a lot faster?
The bottle neck is probably just my inefficient routine that I put together in a rush  After sleeping on it, I came up with a different method this morning for copying & scaling the video buffer more efficiently. I only had a chance to test it on the 3x zoom (288x192 resolution) and it was running at pretty much the same frame rate as the 83+/84+ non CE version. I'll try it later on 2x zoom as well and see how fast it gets, but at a rough calculation it should be about 30% faster than the 83+/84+ non CE frame rate. Either way, it's certainly workable
67
« on: December 21, 2015, 08:37:32 am »
Since 3.5 years ago when I decided to do Alien Breed 5, I've had a rough plan in my head for it to be a 3-part game, ie. the first main release, followed by two additional campaigns with new features to be added later. I've recently started working on the 3rd and (most likely) final part. It's still very early days, but I've already gotten a few cool things done. As usual, there will be a new campaign, although it will be different in structure to Episodes I & II. There will also be new gameplay elements, some new enemies, more achievements and potentially some slight graphics tweaks in the form of more tile animations. So far, I've reworked the level file format to allow for some of the additional gameplay elements, which will allow for more things to happen in levels. The level editor pretty much had to be rebuilt from scratch, as well as making a simple program to convert the existing Episode I & II data to the new format. I'm now halfway through implementing the calculator-side changes to all of this, so that the game correctly interprets the new level format and starts incorporating the new elements. Additionally, whilst this will still include the standard TI-83+/84+ flash application release, over the last 36 hours I've been doing some tests to see how viable it would be to include a build for the TI-84+CE! I've drawn inspiration from MateoConLechuga's Mono2Color project for the TI-84+CSE, and after a few experiments determined that I'll most likely have to stick with monochrome tiles & sprites so that I can run the LCD in 1bpp mode, otherwise the frame rate gets way too slow. Below you can view a demonstration showing the game in 3 different zoom levels (x1, x2 & x3). As you'll see, x1 moves super quick, x2 moves roughly the same speed as the TI-83+/84+ monochrome version (within 1fps), and x3 is a bit slower again (around 7-8fps slower). Of course this demo only includes the scrolling background, no player/enemy/gunfire sprites. However, all the tile drawing & sprite rendering is done on a 768 byte buffer, the part that slows things down is scaling this 96x64 resolution buffer up to either 192x128 (x2) or 288x192 (x3). I'm confident that drawing the sprites over the tilemap will have minimal effect with the CPU speed of the TI-84+CE (but this will be my next few experiments). The 768 video buffer -> vram drawing/scaling routines were written fairly quickly, so I might be able to optimise them a little. I'll continue playing around and see how I can improve it. At the very least, I'd like to have a TI-84+CE version with a play screen of 192x128.
68
« on: April 14, 2015, 12:43:27 am »
Great summary, pimath! And thanks for the mention!
69
« on: February 26, 2015, 05:10:59 am »
I've finally put the character panels & inventory screen in-game, although they're not fully populated as yet. Anyhow, here's a recent screenshot: 
70
« on: February 19, 2015, 11:48:48 pm »
Looking awesome Sorunome!
71
« on: February 19, 2015, 08:31:57 pm »
The last few days have been spent playing around with how the character display will look, as well as the full inventory screen, etc. Once I've finalised these I'll get them into the game and pop up some more screenies I've got a bit of storyline coming together as well. Whilst I don't want to bog down the gameplay with massive amounts of text every few minutes, I'm currently thinking there will be bits of exposition during the game, whether it's via scrolls or something that are collected along the way, or from NPCs, etc.
72
« on: February 18, 2015, 01:41:34 am »
I just downloaded Alien Breed and I really like it! I just wish it saved instead of using passwords.
I have a "quick-save & exit" type feature on my to-do list for the next minor update, which I expect I'll get around to doing in the next couple of months. However I don't plan on having multiple save slots (like RPG type games).
73
« on: February 17, 2015, 02:06:16 pm »
Wow, tons of changes. I wish you'd released this a week earlier as i've had several long bus rides the past couple weeks. Anyway, congrats on the release!
Thanks man! Took me long enough.. 
74
« on: February 17, 2015, 02:05:47 pm »
The ceiling textures staying static does look a bit odd, but it still looks really pretty. Alternating textures would definitely look even nicer, though.
Also, i really like the idea behind this game. I think i played a similar game years ago, an old pseudo-3D RPG written in QBASIC called Legend of Lith. These types of games amazed me back then, it'd be really cool to see something similar for the TI calcs
EDIT: Also, would it not be possible to decompress the textures into RAM when you load a level? I'm not sure how big the textures actually are (or how well they'd compress), but it might be worth looking into if you've got enough RAM (_InsertMem) for it. That way you could store them compressed and it'd just take a split second to decompress them when you load a level.
Thanks! Yeah I'll be doing the alternating floor/ceiling textures once I get around to ripping them from EoB. Technically it would be possible. In uncompressed form, a full set of wall textures (excluding ceiling/floor) takes about 12.1KB. Each map/level is 32x32 blocks, so I'll also need at least 1024 bytes for the current level to be loaded to. If people were happy with having their RAM mostly clear during game execution then I could certainly compress a bunch of textures I'll look at that kind of stuff (compression, etc.) later on anyways, atm I'm working more on movement, the game screen, etc.
75
« on: February 15, 2015, 05:08:31 am »
I think both are great, but I'd vote RPG
Pages: 1 ... 3 4 [5] 6 7 ... 19
|
Show Posts
