Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


svenvandevelde last won the day on March 27

svenvandevelde had the most liked content!

Community Reputation

59 Excellent

About svenvandevelde

  • Birthday 01/31/1970

Recent Profile Visitors

250 profile views
  1. it's going to be a hard work ... There is another question related to Sprite hiding.... How to position sprites beyond the top and left border of the screen? The value zero seems to show the whole Sprite at the top or left border of the screen. On the c64, sprites were hidden at this position. So in vera, how to move sprites up or left beyond these borders?
  2. This method crossed my mind too. But indeed, that impacts performance and it will require to continuously copy sections of memory into VRAM ... It will have CPU overhead ...
  3. What I don't like is the lack of sufficient VRAM in the VERA. Even in 4bpp, memory runs out fast. Especially if you want to embed spritee animations. With the hardware capabilities of the VERA, memory is underscaled when using the high resolution 640x480 in tiled mode. An example ... 12 sprites of 32x32 pixels in 4bpp requires $1800 bytes. But in high resolution 32x32 px is very little. 64x64 px quadruples the memory requirement... then you talk about $6000 bytes. And that is for just one "healthy" sprite animation ... beside that, you need explosions, damaged states, shadows, overlays like glowing effects, bullet types. So per enemy type you can easily consume $8000 to $A000 bytes (when in 64x64). And note that all this is in 4bpp. When using 8bpp that requires a multiple by 2. So 12 sprites in 8bpp 32x32 consumes about $3000 bytes. In 64x64 mode that would be $C000. That's 1/3 of the VERA VRAM, for one healthy enemy. An interactive arcade game would easily have 6 to 8 different enemy types on the screen requiring animations, damage states, bullets, shields, glowing etc. Noting that the VERA has 128 different sprites that can be shown simultaneously I really am afraid that memory upscaling is a requirement to use the full potential of the machine.
  4. Lovely ... Got collision detection working now with VERA hardware detection ... VERA implements collision detection very nice. Thanks to those who have been explaining how collision works on various sites and also here commenting. Especially @AndyMt, @Geehaf and the explanation of flyinglow at this site helped a million times! Sprites in Assembly III - Collision detection (8bitcoding.com). And thanks @Johan Kårlin for showing me the way to hide those sprites... The CX16 default VERA documentation lacks essential details in terms of collision detection. Now I have all the ingredients to continue with my game ... It's exciting. I'll need to do some explosions etc.
  5. The engine I"m building has for each "sprite" a collection of sprites that can be animated, and a structure that defines the sprite height, width, bpp, hflip, vflip and zdepth ... Doing so, allows me to keep all the properties of the sprite settings for a collection of sprites, and it allows sprite animation. The little plane as you can see "rotates" when the mouse goes to the left or to the right. The sprites are stored in banked RAM, and I plan to copy them "on demand" to the vera. I've built a vera "heap" manager, that allows malloc, realloc and free in VRAM, so that sprite allocations can be done dynamically as the game progresses, and I don't need to bother with memory mapping the areas where teh sprite data will be placed in the VRAM when copying from banked RAM ... Hence you can see the "memory dump" on the screen. Got this new term ... VRAM and BRAM ... Side note ... I also have the tile engine ready, which scrolls the background (see Space Game shoot'em up progress ... - X16 Software Library Chat - Commander X16™ Community). Once i have my flight engine working, I'll integrate both engines into one set ... The next thing will be the "enemies"... and then the fun part, sprite collisions and explosions ...
  6. OK. Thank you. I got it working now ...
  7. ah!!!!. I oversaw that! Wonderful! That makes it now easy for me. Thank you very much Johan. I do have a learning curve ...
  8. I am preparing this shoot-em up. But i see that sprites x and y position indexes with 0, are stuck in the visible area of the map (totally at the top left)... What are your techniques to "hide" sprites in the vera card? Because there seems to be only one switch to turn all sprites on or off. In the below picture you see the fired bullets hanging at index y=0 on the top ... So what is the best technique to hide those? If you could maybe share your thoughts or experience ... that would also help others maybe ...
  9. Well ... it would be good to move it now ... but maybe it's too late and as such, this feat will live forever in the x16...
  10. I have exactly the same question. Why was it designed like this. It seems illogical to me.
  11. What would be one of the benefits of transparency is to be able to cast shadows as a layer on top of other objects. It would greatly reduce the amount of tiles you need to setup a shadowy environment. Data would be reduced significantly.
  12. Hi, i'm not a hardware technicial, but does the last sentence mean that the speed of updates was limited? (~50 LEs per color channel)
  13. Hi all, Just want to notify some progress has been made on the shoot'em up game in progress ... Space Flight - Demos - Commander X16™ Community Tile engine has been updated now, and new tiles were generated using various softwares... The explanations are in the game page ... I will post in this threat some of the details how this was all done ... Please have a look how this game is evolving ... Now that I have worked out how to use Blender, i can create bitmaps rendered from 3D models ... Sven
  14. There are these moments when you wake up in the night, due to a problem, question or topic that was floating in your mind for a while, and you just cannot go back to sleep ... . Well, I had such moment :-). So to get peace in my mind, I decided to take action, and ask the X16 forum members about that question, but I wrote the post in the middle of the night (like 2am) using my mobile, and I messed up a bit ... Svennie! For a 4 bit per pixel VERA configuration, you'll have 16 colors, reflected in the palette as 4 bits per color channel, so it would be 12 bits, making 4096 possible color configurations. I mixed up the colors with the bits (sorry). What I wanted to indicate that in the palette registers of the VERA, you have essentially 2 bytes per color offset, 1 byte for GREEN and BLUE, and one byte for RED, leaving 4 bits of that last byte unused... From the VERA manual: So I was thinking, why didn't Mr. Vanderhoef consider to implement an alpha channel (RGBA)? i guess it's just a valid question to ask, isn't it? But now ... the more I think about it, the more I think it would be overkill ... When you realistically would want to reflect tiles in 4 BPP mode, then you'll have essentially 16 colors per tile... If you within this 16 colors would need to reflect color configurations containing an alpha channel, then that would bring an additional dimension to take care off in your color config. Let me give an example: if you have let's say a shaded tile, that would shade from dark yellow to light yellow, and you would want to add "transparency" to that, then your shading palette would be cut by the amount of transparency layers you would want to implement. It's impossible for example to implement a tile with 8 different colors, and 4 transparency layers, because these won't fit into the 16 color configurations (8 x 4 = 32!) ... So not sure now that my question about the alpha channel was a valid one for a retro configuration like the X16 ... It might just indeed be better to deal with a simple one color transparency (black), leaving 15 colors to model your palette for a tile or sprite in 4 BPP mode. My question was all about the underlying, which I will explain in a later post in detail ... Because on this background (which is auto generated), "space" stations and fire units and landing zones will be put, that will allow the player to land and recharge, rearm, repair ... Those stataions will be graphically reflected as sprites, that will kind of scroll with the background scrolling speed. and in order to put those decently on top of the background, it would be nice to have "semi-transparency", so through an alpha channel in the palette color config. I'm afraid that the sprites will look heavily pixellated ... I am very much appreciating the ideas brought up in the above posts by all who contributed, highlighting tactical solutions on the topic with the existing hardware. Sven
  15. Sorry, I wrote my text wrong I see... I'll need to change it ...
  • Create New...

Important Information

Please review our Terms of Use