Page 1 of 3

Getting back into the swing.

Posted: Tue Mar 25, 2014 6:32 am
by hpglow
Since the day I set foot on this site I have wanted to start and finish a project for Uzebox. I have attempted 3 and hit roadblocks on all of them. Part of it is my approach to coding, the other is my lack of exp. I'm a BS of IT with a minor in software development.

Since the time of my graduation 4 years ago I have done nothing but try to get into the field. About 6 months agao I went to an interview that was brutal and I've spent some time just drinking my life away.

I have limited time these days but I'm just trying to rekindle that spark I once had for C code. I doubt I have the time to make a project for the code challenge this year but I do have a couple ideas that may be worth pursuit. So I'm going to drop two of them in your laps and let those who know the kernel best tell me their feasibility.

First, would be an Atari 2600 type game and accompanying video mode. The 2600 or VCS could only display 1 bit sprites but got around this by changing that one color per scan line. So what I'm thinking is define the color first then the array of bits second. Of course this would require custom graphics data. Demon Attack and H.E.R.O. are two games worthy of conversion IMO.

The next option is a limited color mode to save flash and ram space. Something like 5 bits then store the data in 16 bit clusters. Use bit masks to remove the 3 pixels from a 16 bit int and buffer the extra bit for use in stuff like collision data. I don't know if it's possible to do a duo-tone or monochrome mode like this but that is kinda what I envision. It might even be charming to pad every pixel with something like white or light green to give it that old school gameboy or LCD feel. I don't have a project for this mode yet but I've been around long enough I'm sure I could come up with something.

Tell me what you think.

Re: Getting back into the swing.

Posted: Tue Mar 25, 2014 1:34 pm
by Janka
hpglow wrote:The next option is a limited color mode to save flash and ram space. Something like 5 bits then store the data in 16 bit clusters. Use bit masks to remove the 3 pixels from a 16 bit int and buffer the extra bit for use in stuff like collision data. I don't know if it's possible to do a duo-tone or monochrome mode like this but that is kinda what I envision. It might even be charming to pad every pixel with something like white or light green to give it that old school gameboy or LCD feel. I don't have a project for this mode yet but I've been around long enough I'm sure I could come up with something.
I've done some musings about a feasible palette video mode a while ago. It's similar to mode 3.
http://uzebox.org/forums/viewtopic.php?f=3&t=1770
http://uzebox.org/wiki/index.php?title=Video_Mode_11

No code yet, as I've haven't much time to do anything on Uzebox the last year. :cry:

Re: Getting back into the swing.

Posted: Tue Mar 25, 2014 8:49 pm
by CunningFellow
I'd say best thing is to just get back on the horse.

Aim to finish a simple game for the comp.

How about something like a space-wars like vector game. Easy graphics. All the framework for vectors is there. Should not take long.

Re: Getting back into the swing.

Posted: Wed Mar 26, 2014 11:07 am
by CunningFellow
Oh. If you don't know what space wars is
http://www.arcade-museum.com/S/Space_Wars.html

Re: Getting back into the swing.

Posted: Thu Mar 27, 2014 3:52 am
by hpglow
I will look over the code over the next 3 days and get back to see if I can make Space Wars happen.

Re: Getting back into the swing.

Posted: Thu Mar 27, 2014 10:41 pm
by hpglow
I downloaded your code but I get errors. Probably nothing big.

Code: Select all

 undefined reference to `sync_flags'
 undefined reference to `SYNC_FLAG_FIELD'
 undefined reference to `SYNC_FLAG_VSYNC'
 undefined reference to `sync_flags'
Which is odd because I can find all these variables defined in the .c file. I'm not sure why the compiler or linker can't connect the C code to the assembly. I will mess with it more later tonight. I know nothing about assembly, but would it hurt anything for me just to re-define these in the assembly file?

Re: Getting back into the swing.

Posted: Fri Mar 28, 2014 3:37 am
by D3thAdd3r
I would make sure every kernel file you have is up to date. I believe I had just that and then realized I had some outdated files somehow

Re: Getting back into the swing.

Posted: Fri Mar 28, 2014 3:54 am
by hpglow
D3thAdd3r wrote:I would make sure every kernel file you have is up to date. I believe I had just that and then realized I had some outdated files somehow
I will check. I just downloaded what I thought was the newest.

Re: Getting back into the swing.

Posted: Fri Mar 28, 2014 4:03 am
by uze6666
Are you are trying to use CunningFellow's Asteroid game? I didn't yet dwelve into his new mode 6 to merge it the current kernel code base. Would be simpler for me if he did. ;)

Re: Getting back into the swing.

Posted: Fri Mar 28, 2014 4:32 am
by CunningFellow
there is a videoMode6.s/h file in the ZIP that you either have to make sure your compiler can find OR just copy it over the old mode6 file in the kernel directory.