Jump to content

svenvandevelde

Members
  • Posts

    461
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by svenvandevelde

  1. I hope this clarifies a bit what i meant to say ... look at video around 2:30... https://screencast-o-matic.com/watch/c36ebrVtI3J
  2. As I wrote earlier: But thank you for the suggestion. Indeed, it is a good method to do and this would be a solution. However, it would make things way more complicated. I've posted a video below that shows what is in the make. This is way past a demo. It is an actual game, with lots of enemies and thus, sprites ... I want to render them as one object, but will combine the player sprite with additional modules picked up on the flight. However, for the enemies, if i need to model those also, then i am looking at a project to be release in 2 years ... Think the 48x48 is the viable option in my opinion, but only if doable technically. Actually, it would be great if vera would have some function to set the scales of sprites by the user.
  3. Do what i'm doing with vera and then you will see that it is not that simple. And 128x128 would be great, but impossible to manage at acceptable frame rates, as vera and cx16 don't have dma.
  4. I suggest to model it that the high resolution 640 width supports 16, 32, 48, 64 resolutions. And the lower resolution 320 supporting 8, 16, 32, 48? lol
  5. This idea would be a fantastic solution. Other could be that the scheme adapts based on screen width/height setting?
  6. Hi, Before you read further, please keep in mind that this post is not meant to pose any critic to Frank VdH or to the overall design of the CX16 regarding its graphics capabilities ... However, allow me to reflect the followiing ... Using vera in 640x400 graphics mode, there is a function in vera which I believe which could be further fine tuned ... It is the setting of the height and width of sprites ... Sprites can be configured as 8, 16, 32 and 64 width and height by setting the respective bits in register 7 of the sprite attributes... I find the width and height of 64 however a bit too big of a gap. Hopping from 8 to 16 is ok, from 16 to 32 is ok, but from 32 to 64 means that in terms of memory consumption there is a big increase ... Let me illustrate: 8 x 8 in 4bpp requires 32 bytes. 16 x 16 in 4bpp requires 128 bytes. 32 x 32 in 4bpp requires 512 bytes. 64 x 64 in 4bpp requires 2048. In 8 bpp that would be a whopping 4096 bytes! My question is, what if the vera would model the sprite painting with the following width registers: 16, 32, 48, 64, and discard the 8 pixel width and height setting. That would mean, that the following mode would become available: 48 x 48 in 4bpp requires 1152 bytes, in 8bpp that would be 2304 bytes. Additionally: A sprite width/height of 32 x 32 is too limiting, it does not draw sprites with sufficient size. It is a bit too small. A sprite width/height of 64 x 64 is big, which is great, but it consumes too much memory. These kind of sprites would have a more limited animation count to save memory. A sprite width/height of 48 x 48 would be a great size, as this would not consume too much memory, but would show sprites with sufficient pixel size. Please see examples below: Above is an example of a 48 x 48 sprite animation... Above is an animation of a 32 x 32 animation, great but a bit small. However, this size is perfect to flood the screen with enemies :-). But the density to show sprite animations is limited and the width/height quickly becomes obvious to the player that 32x32 is the limit as all sprites will be in this size ... Above shows 64 x 64 sprites animation, great for larger type of enemies, but consumes a lot of space. The 48 x 48 sprite size seems to be the right fit, a 64 x 64 is needed, but consumes a lot of memory. Drawing a 48 x 48 sprite animation results in a lot of vram memory being lost, due to having to draw this 48 x 48 sprite animation on 64 x 64 planes. One could argue, that yes, we can do magic and start combining sprites to make larger pictures to draw a 48x48 bitmap, like drawing 9 16x16 sprites, or 1 sprite of 32x32 + 1 sprite of 16x32 + 1 sprite of 32x16 + 1 sprite of 16x16 ... But that would make things very, very complicated, and also notice by having to draw 9 or 4 sprites instead of one, there is a performance impact. Also notice, that if I would draw a 48x48 sprite out of 9 sprites of 16x16, that would mean 72 sprites to be drawn if i want to show 8 images of 48x48 pixels! Any thoughts on this? @Wavicle?
  7. Thanks for the suggestions but looking for the real deal ...
  8. Where would you buy in Europe an affordable 1351 mouse for my c128 and c64? On Ebay these are really expensive and over priced. Any suggestions?
  9. Gplden ram. Seems like a fine spot to manage and store hash tables of 512 bytes each !
  10. A 1581 on ebay quickly sets you off to 800€ ... I would love to have a working 1581, even in house made. It's just, I don't have the skills to solder and put it all together. I do have some old computer cases with some old 3 1/2 " drives in it. But how to build a new one is a whole other league.
  11. One thing I learn on the CX16 is that in order to do fancy things, like memory resource managers or heap managers, this results in a rather significant footprint of code and data. Like a hash management code and a hash table. Like linked lists and logic to manage these lists.... And the low memory area of the CX16 is limited, so it is important to ensure your game logic plus resource management logic all fits in the 0800 till 9Fxx memory area.
  12. True. The effort these crackers put in making intros or demos should be better spent on making good games.
  13. And it has a richer instruction set, correct? With a z register?
  14. First of all. Amazing and WOW! Secondly ... What is a W65C816S about? Sorry for my silly question. Is this a new processor?
  15. aha! that is it yes! TI$ or TIME$ returns nothing.
  16. Seeing your feedback, I immediately booted up the x16emu and the box16. And yes, they DO seem to have the TI functioning properly! But for sure I've seen zero as a result of PRINT TI ... Not sure however what that was again, but yes, it works!
  17. Note that the TI function on the CX16 R41 emulator returns 0?
  18. Yeah. I see, it is good practice and gives the player a recognition which groups are behind sets of games. There are many more examples like the ones you've posted.
  19. Thank you. Maybe I plan to document it later on but now first want to work on the enemy flow logic a bit more. To make more enemies and make more bullets etc. So that the game get's more attractive, building on the core that is here now. It is also necessary to do, for a good and thorough testing of the game engine. Maybe a video to explain it would do, but also that takes a lot of time to make. Not sure what is the best. Tried to write things down, but that is not interactive at all (with people).
×
×
  • Create New...

Important Information

Please review our Terms of Use