Jump to content

BrianBeuken

Members
  • Posts

    38
  • Joined

  • Last visited

About BrianBeuken

  • Birthday 12/17/1963

Profile Information

  • Gender
    Male

Recent Profile Visitors

1,812 profile views

BrianBeuken's Achievements

Space Invader

Space Invader (2/9)

10

Reputation

  1. Jan is making these carts and boxing them by hand and there is a lot of interest, so please don't be too hard on him if he cant respond/send copies by return post. He's really pleased with the response. Its been one of his life ambitions to produce a game like this and he's overjoyed at the positive comments. (quite pleased myself :D)
  2. This sounds very promising, thanks nanochess, I'm back home this week and will try this again on my hardware and report back to you Brian
  3. Hi all I wonder if I can get some collective help for a strange problem I am having. i've been working on a CV game for some time now, its a collection of mini games and a menu system to tie them together and code wise its all done and dusted, it works perfectly on every emulator I have found, but when I test it on hardware I get a very strange and apparently random corruption of my sprites but only on some of the games, and not always the same ones. I am using the correct terminators in the sprite list I send to the video. and I even make an extra effort to ensure the sprite attrib memory is filled with 192's before I dump my sprite list. but on some of my sub games, the sprites just go crazy.. I can reposition the games and the issue vanishes, though will crop up in another game or not appear again unless I add a few bytes of code. I don't have enough memory now to actrually just add padding until it stops so I have to find a fix.. I've re-written my sprite manager several times now, assuming I'd made some error, but the problem keeps coming back at some other point no matter what methods i use to build the sprite patterns (games usually have 2-3 16x16's to make a game char) The games are arranged to minimise sprite flicker but if it does occur it alters priority to reduce the flicker.. Its very frustrating, the only thing I can think of is if there is some area of ROM or RAM that I am not supposed to be accessing, though I see nothing in the docs that suggest that. So anyone know what is going on? I really want to get this game out on cart but until I can be sure it works on hardware I can' t release it. .
  4. The only real advantage, is running in RAM allows you to use self modifying code which was useful in the early Z80 days on computers to save variable space and make some routines a little faster (direct load of a register is faster than a memory load) several clock cycles can be saved in loops, but with the CV having such a small amount of RAM and its video being tied to the TI chips access clock, there's not a lot to be gained from these kind of code gymnastics. But am sure someone will find a good reason to do it.
  5. I would contest the statement that hand written assembler would only be marginally faster, but it really does depend on the code, and what you were trying to do.. I like C, I would really like to try it out on the CV soon. I'm very curious to see how well the SDCC works.
  6. It does waste a lot of memory, but if the project does not need speed or memory its just far simpler and faster to express coding concepts in C. The stack isn't such a mystery, but yes you do need to take control of it as with all things in assembler, the coder rather than the compiler is in charge, with great power...etc..
  7. do you have any links/sources for it? goggle is failing me?
  8. Although C and other compilers do exist for CV it produces rather slow and bloated code. Originally all CV games were written in Z80 assembler, which is harder to code from scratch but over time you build up libraries of common routines and functions which with macros can result in reasonably fast coding. C will let you produce your code quicker, but CV is a fraction of the speed of the lowest level PC, so you should use the fastest most compact coding system possible, which is assembler.
  9. Thanks, I hadn't tried to use CVgraphictoolkit for bitmaps, it does seem to do the job, I'll test it out.
  10. Hey all, I'm in the very final phases of my project, a port of a classic C64 game, which I will let my publisher tell you about when its ready, but I have been trying to touch up some of the artwork and finding it such a chore. I know we have the IPCH toolkit which is very useful on a character by character basis, but really quite limited when it comes to designing full screens or small sections of screen, sometimes you just want to draw a line from a to b on screen and let the internals take care of the chars I am painfully aware the 2 colour system on the TMS chips and the grouping of 8 chars per colour is problematic, but are there any art packages around, perhaps even on MSX that will let me draw screen based art, swapping to new character group and producing finally a character set and name table I can then use in games? If not, is this something others would find useful if I wrote one? cheers and watch this space for more details
  11. I just checked the uridum video and yes I do understand this concept for horizontal scrolling which is relatively simple but eats ROM (there's always a compromise( I'm really looking to find a way to do smooth 8 way scroll, all the examples quoted show only a vert or horizontal system, apart from the Burning rubber game which makes a damn good attempt at 8 way using simplified graphics to allow for reduction of work. Back in my Spectrum/Amstrad days we just used to dump recalculated screens to the visible screen but that's not practical on a low RAM, char map based screen.......creates an interesting and difficult proble
  12. ok but all this really allows you to do is create a (near) screen size character map that you can dump a bitmap to? I assume scrolling is then done by dumping to via x and y offsets into that buffer....but that's going to require a massive RAM buffer that's not available on the standard CV..hmmm So what are these undocumented features?
  13. I assume you are only writing to the VDP during the vblank refresh then? that's a good example of 8 ways scroll but yes it highlights how simple the graphics need to be so you're not redefining hundreds of chars.
  14. hmmm yes very nicely done on vertical or horz scroll, but none of those techniques would allow for a true smooth 50hz 8 way scroll unless the graphics were incredibly simplified. Writing extensive bitmaps is extremely time costly and that's the principle needed to get uridium and other 8 way scrollys to work... does the SGM provide scrolling?
  15. How would you handle the scrolling on CV since the TI chip does not support any kind of native scrolling?
×
×
  • Create New...